Mailman 3 February 2014 - pypy-dev

Cross-post from python-ideas: Compressing the stack on the fly
by Ram Rachum 28 Jul '14

28 Jul '14

Hi guys, I made a post on the Python-ideas mailing list that I was told might be relevant to Pypy. I've reproduced the original email below. Here is the thread on Python-ideas with all the discussion.<https://groups.google.com/forum/?fromgroups#!topic/python-ideas/hteGSNTyC_4> -------------- Hi everybody, Here's an idea I had a while ago. Now, I'm an ignoramus when it comes to how programming languages are implemented, so this idea will most likely be either (a) completely impossible or (b) trivial knowledge. I was thinking about the implementation of the factorial in Python. I was comparing in my mind 2 different solutions: The recursive one, and the one that uses a loop. Here are example implementations for them: def factorial_recursive(n): if n == 1: return 1 return n * factorial_recursive(n - 1) def factorial_loop(n): result = 1 for i in range(1, n + 1): result *= i return result I know that the recursive one is problematic, because it's putting a lot of items on the stack. In fact it's using the stack as if it was a loop variable. The stack wasn't meant to be used like that. Then the question came to me, why? Maybe the stack could be built to handle this kind of (ab)use? I read about tail-call optimization on Wikipedia. If I understand correctly, the gist of it is that the interpreter tries to recognize, on a frame-by-frame basis, which frames could be completely eliminated, and then it eliminates those. Then I read Guido's blog post explaining why he doesn't want it in Python. In that post he outlined 4 different reasons why TCO shouldn't be implemented in Python. But then I thought, maybe you could do something smarter than eliminating individual stack frames. Maybe we could create something that is to the current implementation of the stack what `xrange` is to the old-style `range`. A smart object that allows access to any of a long list of items in it, without actually having to store those items. This would solve the first argument that Guido raises in his post, which I found to be the most substantial one. What I'm saying is: Imagine the stack of the interpreter when it runs the factorial example above for n=1000. It has around 1000 items in it and it's just about to explode. But then, if you'd look at the contents of that stack, you'd see it's embarrassingly regular, a compression algorithm's wet dream. It's just the same code location over and over again, with a different value for `n`. So what I'm suggesting is an algorithm to compress that stack on the fly. An algorithm that would detect regularities in the stack and instead of saving each individual frame, save just the pattern. Then, there wouldn't be any problem with showing informative stack trace: Despite not storing every individual frame, each individual frame could still be accessed, similarly to how `xrange` allow access to each individual member without having to store each of them. Then, the stack could store a lot more items, and tasks that currently require recursion (like pickling using the standard library) will be able to handle much deeper recursions. What do you think? Ram.

2 1

Regression for lxml-cffi install (?)
by Костя Лопухин 16 Apr '14

16 Apr '14

Hello! https://bugs.pypy.org does not work at the moment, so posting here. pip install -e git+git://github.com/amauryfa/lxml.git@cffi#egg=lxml-cffi works under pypy 2.1 and fails with pypy nighly. Not sure that this does really belong to pypy bugtracker, but it looks like a regression. Tested under Ubuntu 12.04 and OS X, on the same machines. In order to install lxml from source on ubuntu 12.04, I installed the following ubuntu packages: libxml2 libxslt1-dev zlib1g-dev pypy nighly (it failed on older nightlies too, and I can check on other releases if needed) Python 2.7.3 (8df8a01902f8, Feb 27 2014, 23:00:44) [PyPy 2.3.0-alpha0 with GCC 4.6.3] on linux2 Error under OS X (here error message is better than with gcc): VerificationError: CompileError: command 'cc' failed with exit status 1 Complete output from command python setup.py egg_info: src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c:1555:18: warning: incompatible pointer types initializing 'xmlBuffer **' (aka 'struct _xmlBuffer **') with an expression of type 'xmlBufPtr *' (aka 'struct _xmlBuf **') [-Wincompatible-pointer-types] { xmlBuffer * *tmp = &p->buffer; (void)tmp; } ^ ~~~~~~~~~~ src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c:1556:18: warning: incompatible pointer types initializing 'xmlBuffer **' (aka 'struct _xmlBuffer **') with an expression of type 'xmlBufPtr *' (aka 'struct _xmlBuf **') [-Wincompatible-pointer-types] { xmlBuffer * *tmp = &p->conv; (void)tmp; } ^ ~~~~~~~~ src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c:1603:11: error: cannot take the address of an rvalue of type 'const xmlChar *' (aka 'const unsigned char *') return (&XML_XML_NAMESPACE); ^~~~~~~~~~~~~~~~~~ 2 warnings and 1 error generated. Building lxml version 3.2.1. Building without Cython. Using build configuration of libxslt 1.1.28 Building against libxml2/libxslt in the following directory: /opt/local/lib Full error under Ubuntu 12.04: (testlxml_nighly)[DEV] kostia@dev ~ $ pip install -e git+git://github.com/amauryfa/lxml.git@cffi#egg=lxml-cffi Obtaining lxml-cffi from git+git://github.com/amauryfa/lxml.git@cffi#egg=lxml-cffi Updating ./testlxml_nighly/src/lxml-cffi clone (to cffi) Running setup.py (path:/home/kostia/testlxml_nighly/src/lxml-cffi/setup.py) egg_info for package lxml-cffi src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c: In function '_cffi_var_XML_XML_NAMESPACE': src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c:1603:11: error: lvalue required as unary '&' operand Building lxml version 3.2.1. Building without Cython. Using build configuration of libxslt 1.1.26 Building against libxml2/libxslt in the following directory: /usr/lib/x86_64-linux-gnu Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "app_main.py", line 578, in run_it File "<string>", line 17, in <module> File "/home/kostia/testlxml_nighly/src/lxml-cffi/setup.py", line 220, in <module> **setup_extra_options() File "/home/kostia/testlxml_nighly/src/lxml-cffi/setup.py", line 131, in setup_extra_options STATIC_CFLAGS, STATIC_BINARIES) File "setupinfo.py", line 161, in ext_modules import lxml.etree File "src/lxml/../lxml-cffi/etree.py", line 7, in <module> from .apihelpers import _assertValidNode, _assertValidDoc File "src/lxml/../lxml-cffi/apihelpers.py", line 3, in <module> from .includes.etree_defs import _isString, _getNs, _isElement File "src/lxml/includes/../../lxml-cffi/includes/etree_defs.py", line 1, in <module> from . import tree File "src/lxml/includes/../../lxml-cffi/includes/tree.py", line 490, in <module> libraries=['xml2']) File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/api.py", line 339, in verify lib = self.verifier.load_library() File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/verifier.py", line 74, in load_library self._compile_module() File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/verifier.py", line 139, in _compile_module outputfilename = ffiplatform.compile(tmpdir, self.get_extension()) File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/ffiplatform.py", line 25, in compile outputfilename = _build(tmpdir, ext) File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/ffiplatform.py", line 50, in _build raise VerificationError('%s: %s' % (e.__class__.__name__, e)) VerificationError: CompileError: command 'cc' failed with exit status 1 Complete output from command python setup.py egg_info: src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c: In function '_cffi_var_XML_XML_NAMESPACE': src/lxml-cffi/includes/__pycache__/_cffi__gd9dd9435x1886a454.c:1603:11: error: lvalue required as unary '&' operand Building lxml version 3.2.1. Building without Cython. Using build configuration of libxslt 1.1.26 Building against libxml2/libxslt in the following directory: /usr/lib/x86_64-linux-gnu Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "app_main.py", line 578, in run_it File "<string>", line 17, in <module> File "/home/kostia/testlxml_nighly/src/lxml-cffi/setup.py", line 220, in <module> **setup_extra_options() File "/home/kostia/testlxml_nighly/src/lxml-cffi/setup.py", line 131, in setup_extra_options STATIC_CFLAGS, STATIC_BINARIES) File "setupinfo.py", line 161, in ext_modules import lxml.etree File "src/lxml/../lxml-cffi/etree.py", line 7, in <module> from .apihelpers import _assertValidNode, _assertValidDoc File "src/lxml/../lxml-cffi/apihelpers.py", line 3, in <module> from .includes.etree_defs import _isString, _getNs, _isElement File "src/lxml/includes/../../lxml-cffi/includes/etree_defs.py", line 1, in <module> from . import tree File "src/lxml/includes/../../lxml-cffi/includes/tree.py", line 490, in <module> libraries=['xml2']) File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/api.py", line 339, in verify lib = self.verifier.load_library() File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/verifier.py", line 74, in load_library self._compile_module() File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/verifier.py", line 139, in _compile_module outputfilename = ffiplatform.compile(tmpdir, self.get_extension()) File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/ffiplatform.py", line 25, in compile outputfilename = _build(tmpdir, ext) File "/home/chtd/pypy-c-jit-69524-8df8a01902f8-linux64/lib_pypy/cffi/ffiplatform.py", line 50, in _build raise VerificationError('%s: %s' % (e.__class__.__name__, e)) VerificationError: CompileError: command 'cc' failed with exit status 1 ---------------------------------------- Cleaning up...

2 2

performance problems with Krakatau
by Robert Grosse 13 Apr '14

13 Apr '14

Hi, I have been trying to use Pypy to speed up the Krakatau decompiler ( https://github.com/Storyyeller/Krakatau). It is a large, pure Python application with several compute intensive parts, so I thought it would work well. Unfortunately, there is no clear speedup, and Pypy requires several times as much memory as well, making it unusual for larger inputs. For example, decompiling a quarter of ASM, I got the following results (execution time, memory usage) cpython 64 - 62.5s, 102.6kb cpython 32 - 69.2s, 54.5kb pypy 2.1.0 - 106.5s, 277.8kb pypy 2.2.1 - 109.2s, 194.6kb Sometimes, 2.2.1 is faster than 2.1.0, but they're both clearly much worse than CPython. These tests were performed on Windows 7 64bit using the prebuilt 32bit binaries of Pypy. I tested the 32bit version of CPython too, to see if the problem was a lack of 64bit support. However, CPython 32bit also vastly outperformed Pypy. Execution time was measured using time.time(). Memory usage was measured by watching the Windows Resource Manager and recording the peak Private value. Similar patterns were seen in Working Set, etc. I thought the increased memory usage at least might be explained by constant overhead from compiled code or from it not running long enough to trigger full garbage collection. However, Pypy continues to use several times as much memory on much larger examples. Does anyone know what could be going on here? Pypy isn't normally slower than CPython. Is there a way for me to tell what the problem is?

2 11

Python vs pypy: interesting performance difference [dict.setdefault]
by David Naylor 10 Mar '14

10 Mar '14

Hi, I needed to create a cache of date and time objects and I wondered what was the best way to handle the cache. For comparison I put together the following test: <file="iforkey.py"> import datetime import random import timeit ranges = [datetime.datetime(2011,01, random.randint(1, 31)) for i in xrange(1000)] def ifdict(): cache = {} b = [] for i in ranges: key = i.day if key in cache: b.append(cache[key]) else: date = i.date() cache[key] = date b.append(date) def keydict(): cache = {} b = [] for i in ranges: key = i.day try: b.append(cache[key]) except KeyError: date = i.date() cache[key] = date b.append(date) def defaultdict(): cache = {} b= [] for i in ranges: b.append(cache.setdefault(i, i.date())) print "ifdict:", timeit.repeat("ifdict()", "from __main__ import ifdict", number=10000) print "keydict:", timeit.repeat("keydict()", "from __main__ import keydict", number=10000) print "defaultdict:", timeit.repeat("defaultdict()", "from __main__ import defaultdict", number=10000) </file> # python iforfile.py ifdict: [2.432887077331543, 2.4002890586853027, 2.397233009338379] keydict: [2.3483030796051025, 2.358638048171997, 2.314802885055542] defaultdict: [3.5384328365325928, 3.5329859256744385, 3.5728111267089844] # pypy iforfile.py (pypy 1.5) ifdict: [0.8129069805145264, 0.74648118019104, 0.7432689666748047] keydict: [0.5187451839447021, 0.4662129878997803, 0.4504108428955078] defaultdict: [37.98510789871216, 37.859113931655884, 37.92770600318909] Pypy displays significant slowdown in the defaultdict function, otherwise displays its usual speedup. To check what is the cause I replaced i.date() with i.day and found no major difference in times. It appears dict.setdefault (or it's interaction with jit) is causing a slow down. Regards

4 14

slow-ish multithreaded primitives
by Dima Tisnek 10 Mar '14

10 Mar '14

Hey all, I wrote some threaded code and ran it under different version of python, and unexpectedly high overhead is observed: cpython 2.6.8. cpython 2.7.6, pypy 2.2.1: 14~53ms cpython 3.3.4: pypy 2.1.0 beta py3 mode: <1ms is someone here interested in getting to the bottom of it? or getting pypy py2 mode in line with py3 mode? the set up: 1 lock 2 threads each thread has own condition variable both condition variables share the lock mentioned above. threads wake each other up in turn. arch x86_64, linux 3.12.9, up to date libc/rt/pthread sorry I don't have code handy, it's part of a larger project, but if someone's interested, please reply and I'll hack up a short test case. thanks, d.

4 10

pypy 2.2.1 win32
by norbert.raimund.leisner＠arcor.de 07 Mar '14

07 Mar '14

Hello support-team, I have installed pypy 2.2.1 win32 for my OS Windows XP SP 3 -32 bit, Python 2.7, MSI Microsoft Visual C++ 2008 SP1 Redistributable Package (x86). Now my question: Must be Python 2.7 deinstalled and replaced by Pythonv2.7.6 or not? I ask you because a chess program "Sunfish" https://github.com/thomasahle/sunfish/ is using pypy. Best wishes, Norbert

4 6

unaligned raw_load (align_float_cast branch)
by matti picus 26 Feb '14

26 Feb '14

I would like to ask for help with this branch, as I have not been able to move it forward fast enough. micronumpy tests crash on ARM, due to issues accessing raw memory in struct arrays. It turn out that casting unaligned memory to a float or double causes a segfault on ARM, I started to fix this on the align_float_cast branch. I wrote some tests, added some XXX in places that seem to call raw_load, but got stuck trying to fix the test in test_rawstorage that uses RawStorageGetitemEntry in rlib/rawstorage. It is not clear to me how to add the "allocate temporary aligned memory, copy from unaligned memory, cast" trick using HighLevelOps in the RawStorageGetitemEntry class. Should this use a piece of C instead? Please help by either committing some code or pointing out how to move forward. Matti

4 6

Virtualizable Frames getting half removed in trace
by Timothy Baldridge 26 Feb '14

26 Feb '14

This may be a bit of a long post, but I'm trying to provide as much information as possible. I'm attempting to work on a minimalistic Clojure friendly VM. The bytecode is quite a bit like Python and the program I'm testing looks something like this: add-fn (make-code :bytecode [ADD RETURN] :vars [] :consts [] :locals 0 :stacksize 2) inner-code (make-code :bytecode [STORE_LOCAL 2 PUSH_CONST, 0, STORE_LOCAL, 0, NO_OP, ; 6 PUSH_LOCAL, 0, PUSH_LOCAL, 2, EQ, COND_JMP, 26, PUSH_LOCAL 0 PUSH_CONST 1 PUSH_CONST 2 INVOKE 2 STORE_LOCAL, 0, JMP, 6, NO_OP, ;21 PUSH_LOCAL, 0, RETURN] :vars [] :consts [0 1 add-fn] :stacksize 5 :locals 3) outer-code (make-code :bytecode [PUSH_CONST, 0, PUSH_CONST, 1, INVOKE, 1, RETURN] :vars [] :consts [100000, inner-code] :stacksize 2 :locals 0) This program simply increments a local from 0 to 100000. When I tested this using ADD in the inner-code, I ended up with a very tight trace. However, when I added, add-fn the frame for inner trace ends up getting half created at some points. The code for the main interpreter is here: https://bitbucket.org/halgari/clojure-vm/src/a95d278c7540cd16efb025f878c377… I'm attaching a copy of my latest trace. The part I'm not happy with is at the end of the trace: debug_merge_point(0, 0, 'INVOKE 2') p64 = new_array(1, descr=<ArrayP 8>) +1165: p65 = call(ConstClass(ll_mul__GcArray_Ptr_GcStruct_objectLlT_arrayPtr_Signed), p64, 2, descr=<Callr 8 ri EF=4>) +1251: guard_no_exception(descr=<Guard0x1006f66b0>) [p0, p65, p60, p6, p8, p16, p18] +1299: setarrayitem_gc(p65, 0, p60, descr=<ArrayP 8>) +1338: setarrayitem_gc(p65, 1, ConstPtr(ptr37), descr=<ArrayP 8>) p67 = new_array(2, descr=<ArrayP 8>) +1446: setarrayitem_gc(p67, i30, p60, descr=<ArrayP 8>) +1451: p68 = getarrayitem_gc(p65, 1, descr=<ArrayP 8>) +1462: setarrayitem_gc(p67, i40, p68, descr=<ArrayP 8>) debug_merge_point(1, 1, 'ADD') +1474: p69 = getarrayitem_gc(p67, i48, descr=<ArrayP 8>) +1479: setarrayitem_gc(p67, i48, ConstPtr(null), descr=<ArrayP 8>) +1488: p70 = getarrayitem_gc(p67, i52, descr=<ArrayP 8>) +1500: setarrayitem_gc(p67, i52, ConstPtr(null), descr=<ArrayP 8>) +1509: i71 = getfield_gc(p69, descr=<FieldS clojure.vm.primitives.Integer.inst_int_value 8>) +1513: i72 = getfield_gc(p70, descr=<FieldS clojure.vm.primitives.Integer.inst_int_value 8>) +1517: i73 = int_add(i71, i72) p74 = new_with_vtable(4297160080) +1531: setfield_gc(p74, i73, descr=<FieldS clojure.vm.primitives.Integer.inst_int_value 8>) +1535: setarrayitem_gc(p67, i52, p74, descr=<ArrayP 8>) debug_merge_point(1, 1, 'RETURN') +1540: p75 = getarrayitem_gc(p67, i52, descr=<ArrayP 8>) +1545: setarrayitem_gc(p67, i52, ConstPtr(null), descr=<ArrayP 8>) debug_merge_point(0, 0, 'STORE_LOCAL 0') debug_merge_point(0, 0, 'JMP 6') debug_merge_point(0, 0, 'NO_OP') +1554: jump(p0, p75, p6, p8, p16, p18, i21, i30, i40, i48, i52, descr=TargetToken(4302274768)) I'm not sure why these allocations aren't getting removed. Any thoughts? Thanks, Timothy

4 7

Very slow Julia example on PyPy/numpy - can you help me understand why it is slow?
by Ian Ozsvald 25 Feb '14

25 Feb '14

Hello all. I'm talking at PyData London this Saturday on the 'high performance landscape', pypy and pypy/numpy get discussed. PyPy and lists works great on my Julia example, the pypy/numpy version is very poor with respect to other solutions (cython, pythran, numba). Can you help me understand what's wrong? I'd like to give a sensible answer to the audience. I'll also note in the talk that this result is still 10* faster than Python+numpy used the same way. Sidenote - on a separate example (for my book) using Monte Carlo Pi estimation with a 1e7 vector, pypy/numpy is 2* slower than python/numpy (which obviously isn't bad), so I'm fairly confident my pypy/numpy code is working correctly. This example uses a vectorised operation. I'm using a fresh daily build of pypy and a fresh checkout of numpy. Here's the main function, I'll copy the full example down below: def calculate_z(maxiter, zs, cs, output): """Calculate output list using Julia update rule""" for i in range(len(zs)): # range, xrange - same speed n = 0 z = zs[i] c = cs[i] # expanding the math make it 2 seconds slower #while n < maxiter and (z.real * z.real + z.imag * z.imag) < 4: # using a for loop in place of while makes it 1 second slower # using direct array references (removing z,c) does not change speed while n < maxiter and abs(z) < 2: z = z * z + c n += 1 output[i] = n I pass in 2 np arrays as complex128 (zs has co-ords, cs is a constant - this is a consistent example in my book which looks at cpu and memory costs etc). I iterate with a while loop doing some simple math. Cython+numpy takes 0.19s. (similar results for numba, pythran) PyPy+numpy takes 5s. Python+numpy takes 54s (due to dereference cost on each array access) Is the problem related to dereferencing? I'm not doing a vectorised operation for this example. I know that dereferencing each element using Python+numpy is horribly slow. Ian. Full code: """Julia set generator without optional PIL-based image drawing""" import time import numpy as np # area of complex space to investigate x1, x2, y1, y2 = -1.8, 1.8, -1.8, 1.8 c_real, c_imag = -0.62772, -.42193 def calculate_z(maxiter, zs, cs, output): """Calculate output list using Julia update rule""" for i in range(len(zs)): # range, xrange - same speed n = 0 z = zs[i] c = cs[i] # expanding the math make it 2 seconds slower #while n < maxiter and (z.real * z.real + z.imag * z.imag) < 4: # using a for loop in place of while makes it 1 second slower # using direct array references (removing z,c) does not change speed while n < maxiter and abs(z) < 2: z = z * z + c n += 1 output[i] = n def calc_pure_python(desired_width, max_iterations): """Create a list of complex co-ordinates (zs) and complex parameters (cs), build Julia set and display""" x_step = (float(x2 - x1) / float(desired_width)) y_step = (float(y1 - y2) / float(desired_width)) x = [] y = [] ycoord = y2 while ycoord > y1: y.append(ycoord) ycoord += y_step xcoord = x1 while xcoord < x2: x.append(xcoord) xcoord += x_step # build a list of co-ordinates and the initial condition for each cell. # Note that our initial condition is a constant and could easily be removed, # we use it to simulate a real-world scenario with several inputs to our function zs = [] cs = [] for ycoord in y: for xcoord in x: zs.append(complex(xcoord, ycoord)) cs.append(complex(c_real, c_imag)) zs_np = np.array(zs, np.complex128) cs_np = np.array(cs, np.complex128) print "Length of x:", len(x) print "Total elements:", len(zs) start_time = time.time() output = np.empty(len(zs), dtype=np.int64) calculate_z(max_iterations, zs_np, cs_np, output) end_time = time.time() secs = end_time - start_time print "Took", secs, "seconds" validation_sum = sum(output) print "Total sum of elements (for validation):", validation_sum # Calculate the Julia set using a pure Python solution with # reasonable defaults for a laptop calc_pure_python(desired_width=1000, max_iterations=300) -- Ian Ozsvald (A.I. researcher) ian(a)IanOzsvald.com http://IanOzsvald.com http://MorConsulting.com/ http://Annotate.IO http://SocialTiesApp.com/ http://TheScreencastingHandbook.com http://FivePoundApp.com/ http://twitter.com/IanOzsvald http://ShowMeDo.com

4 7

PySide with PyPy
by Johan Råde 25 Feb '14

25 Feb '14

Hi everyone, I'm trying to get PySide to run with PyPy using the Python C-API. I'm able to build and install PySide under PyPy on Windows, without any errors, but the installed libraries do not work. I'm working on it. Anyone wants to give it a try on Linux? Maybe the problem is Windows specific. Here is my recipe for building PySide with PyPy: 1. Install the prerequisites: * CMake * Qt (4.6, 4.7, 4.8 are said to work; I used Qt 4.8.5, the latest Qt 4 version) * iconv, libxml2, libxslt (Not sure if they really are needed.) 2. The sphinx package can cause problems. If you don't have sphinx installed or if you have sphinx 1.1.3 installed, then you are fine. But if you have sphinx 1.2.1 (the latest version) installed, then the build will fail. (This is a known PySide issue.) 3. Replace <pypy-prefix>/include/Python.h with the following patched version: https://dl.dropboxusercontent.com/u/525329/PySide/Python.h I have added definitions of two C-API functions, PyUnicode_Concat and PyCFunction_Call, that are missing in PyPy. 4. To make the build work, I had to create a directory <pypy-prefix>/libs and copy <pypy-prefix>/include/python27.lib there. This might be different on Linux. 5. Download the following patched version of the PySide installation package: https://dl.dropboxusercontent.com/u/525329/PySide/PySide-1.2.1-patched.zip I have fixed some bugs in the PySide code. 6. Unzip PySide-1.2.1-patched.zip and run setup.py. I used the command pypy setup.py bdist_egg --qmake=c:\qt-4.8.5-vs2008\bin\qmake.exe If you have only one Qt version installed, then you can probably skip the --qmake option. If you have more than one Qt version installed, use the --qmake option to specify which Qt version to use. On my laptop, the build takes about 20 minutes. --Johan

2 3