Anton Gulenko | 24 Apr 12:38 2014

Virtualizables in RPython

Dear developers,

I am currently working on my Masters thesis about optimizations for SPy (Squeak VM written using the RPython toolchain).
I am planning to devote one or two chapters to the issue of virtualizable objects in a VM like SPy (and also in SPy in particular).
Since there is not much documentaion on virtualizables available, I would appreciate your input. I want to collect details about the underlying concept, and also about the specific implementation in the RPython JIT. For example, was this concept first introduced in Pypy, or is it an older idea? How exactly does the optimizer decide which objects can be virtualized, and which can not?
I would also appreciate pointers to relevant parts of the Pypy source code, which is probably the best documentation as of now.

Thank you and best regards,
pypy-dev mailing list
pypy-dev <at>
Martin Koch | 23 Apr 15:39 2014

pickle/cPickle bug

Hi list

I have found what appears to be a bug in the pickle and cPickle library in pypy. I can reproduce it both on linux and mac. Basically, I can't unpickle a file if it has been pickled with a file object returned by open(), but it works if I use the with construct. The problem is present both using pickle and cPickle. 

On mac, the pypy version is 
Python 2.7.3 (87aa9de10f9c, Nov 24 2013, 20:57:21)
[PyPy 2.2.1 with GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)]

On linux, the pypy version is
Python 2.7.3 (2.2.1+dfsg-1, Jan 24 2014, 10:12:37)
[PyPy 2.2.1 with GCC 4.6.3]

#import cPickle as pickle
import pickle

l = range(10)
# fails:
    pickle.dump(l, open('f', 'wb'))
    print pickle.load(open('f', 'rb'))
except EOFError:
    print("Yup, that's an EOFError")

with open('f', 'wb') as f:
   pickle.dump(l, f)

with open('f', 'rb') as f:
   print pickle.load(f)

If I instead of using open() inline in the argument to pickle assign it to a variable and explicitly close the file after calling pickle.dump, then the problem goes away:

    f = open('f', 'wb')
    pickle.dump(l, f)
    print pickle.load(open('f', 'rb'))

Apparently, in the first code snippet, the file isn't closed as it should be when the object returned by open() goes out of scope after pickle.dump.

/Martin Koch
pypy-dev mailing list
pypy-dev <at>
Kevin Modzelewski | 22 Apr 21:29 2014

Benchmark that pypy doesn't do well on

Hi all, I've finally gotten around to open-sourcing some old code of mine (coincidentally, the predecessor to Pyston) which doesn't perform that well on PyPy.  It's not the best benchmark, since it's not deterministic and produces different results on PyPy and CPython (due to dict ordering, I think), but PyPy seems to be consistently 20-30% slower than CPython, so I think the overall effect is reliable even if the exact numbers aren't meaningful.  The benchmark is "real code" in that I simply added a benchmark mode to a real project, where the benchmark runs the exact same thing as a normal invocation (except for disabling some disk output); I'm definitely not trying to claim that the benchmark is "representative" in any sense, though.

To run it:
cd ~ # needs to be in the home directly unfortunately
git clone
# set up python env
time bash icbd/icbd/type_analyzer/ bench

On my machine, CPython runs it in 60s, but PyPy takes 75s; this is on PyPy 1.8 since I can't get a newer version, but I get similar results with 2.2.1.  I should mention that the program doesn't use any non-stdlib modules, at least in "bench" mode.

I've also tried to extract a part of the program that seemed to run significantly slower under PyPy, and got this microbenchmark:

It takes about 13s for PyPy, and about 4s for CPython.  This microbenchmark is only based on the final phase of the program (the part right before printing all the colored output), so I don't think it's necessarily that representative, it's just something I happened to notice was much slower.

Just wanted to send it over in case you guys were interested.

pypy-dev mailing list
pypy-dev <at>
Matti Picus | 22 Apr 20:35 2014

2.3 release is close, please help triage the open bugs

The consensus on IRC is that we are ready to release PyPy 2.3 Please
help triage the bugs on, and mark your favorite
release-critical one with the 2.3 Release tag. We could also use a name
for the release, suggestions are welcome. For an idea as to what
changed, see
the release notice

Ryan Gonzalez | 21 Apr 20:37 2014

Blocked Block error

First, a quick apology: I don't want anyone to feel like I'm abusing the list or something. I just really need help, and StackOverflow isn't necessarily RPython-friendly.

What I want to know is the meaning of the Blocked Block error. I always get that error at least once. Usually I can solve it myself, but I'm curious as to what it actually means.

If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23( <at> #Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

pypy-dev mailing list
pypy-dev <at>
Ryan Gonzalez | 18 Apr 00:42 2014

Alternatives to multiple inheritance

I’m writing a scripting language using RPython. I have a base class for all my objects. Now, I have an exception object. The exception object needs to derive from my base class in order for me to use polymorphism inside the interpreter. However, it also needs to derive from the Exception class to be throwable. My code looked kind of like this:

class BaseObject(object): pass class MyException(BaseObject, Exception): ...

However, upon trying to compile the code, I got this error:

[translation:ERROR] AssertionError: multiple inheritance only supported with _mixin_: <class 'bolt.objects.BoltException'> [translation:ERROR] Processing block: [translation:ERROR] block <at> 122 is a <class 'rpython.flowspace.flowcontext.SpamBlock'> [translation:ERROR] in (bolt.main:10)parse_and_run [translation:ERROR] containing the following operations: [translation:ERROR] v0 = simple_call((type interpreter)) [translation:ERROR] --end--

bolt.objects.BoltException is my exception class. If I remove the Exception base, I get this:

[translation:ERROR] AssertionError [translation:ERROR] Processing block: [translation:ERROR] block <at> 9 is a <class 'rpython.flowspace.flowcontext.SpamBlock'> [translation:ERROR] in (bolt.main:4)run_file [translation:ERROR] containing the following operations: [translation:ERROR] v0 = simple_call((function create_file), p_0, ('r')) [translation:ERROR] v1 = getattr(v0, ('read')) [translation:ERROR] v2 = simple_call(v1) [translation:ERROR] v3 = simple_call((function parse_and_run), v2) [translation:ERROR] v4 = getattr(v0, ('close')) [translation:ERROR] v5 = simple_call(v4) [translation:ERROR] --end--

The only thing about multiple inheritance and RPython I found was this.

My current idea is to have my base object derive from Exception instead of nothing. I was wondering if there’s a better solution, however.

If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23( <at> #Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."

pypy-dev mailing list
pypy-dev <at>
Ronan Lamy | 16 Apr 16:21 2014

Re: RPython as a separate package

Le 16/04/14 05:59, Bogdan Opanchuk a écrit :
> Hi Benjamin,
> Thank you, I've seen it in the repo. But one still cannot install it
> as a separate package, say, in CPython, and it's not even available as
> a package in the PyPy itself (it's only used at build stage, as far as
> I understand). Are there any plans to complete the splitting and make
> it a standalone package?

There are no firm plans, but it is still a goal. There are a few issues 
to solve first, though:

* Unbundling pytest and py lib
* Cleaning up and splitting the docs between PyPy and RPython
* Deciding what to do with the repository
Armin Rigo | 16 Apr 10:45 2014

Re: RPython as a separate package

Hi Bogdan,

On 16 April 2014 06:59, Bogdan Opanchuk <mantihor <at>> wrote:
> it's not even available as a package in the PyPy itself

What do you mean?  "rpython" is the name of the top-level directory
we're talking about, with "" and everything.  It is a
regular package.

A bientôt,

pypy-dev mailing list
pypy-dev <at>
Bogdan Opanchuk | 16 Apr 06:31 2014

RPython as a separate package


I would like to use the RPython toolchain in my project. The problem
is, RPython is currently hidden inside PyPy and therefore not readily
available. I found this thread
which goes as far as to state "Note that the fact of splitting this is
not up to discussion, however, how we go about it is.". So, what is
the status of the splitting? Was this idea eventually abandoned?
Armin Rigo | 15 Apr 12:55 2014


Hi OS/X'ers,

I see in rpython/translator/platform/ that we use only
"clang" as the compiler on OS/X.  There was some discussion in #pypy,
as well as a proposal from Andrew Dalke to upgrade the gcc on the OS/X
buildbot, which go along the lines of "clang is not necessarily always
better than gcc on OS/X".  So I would like that the RPython toolchain
supports both choices.

Please don't discuss clang-vs-gcc endlessly here, I'm sure there are
people who think that clang is better than gcc and others that have
the opposite view and both camps have strong opinions -- that's not
the point and I don't honestly care.  This e-mail is *only* about
supporting both choices.

Could someone on OS/X check that we can use gcc to translate pypy's?
This can be checked by trying out a smaller example, like
rpython/translator/goal/ .  What fixes do you
need in  Or simply pass some environment variable? Thanks!

A bientôt,

pypy-dev mailing list
pypy-dev <at>
Mike Mezeul | 15 Apr 05:59 2014

PyPy support for PPC processors



Does anyone have any insight as to why the support for Power PC processors has stalled?


I’m specifically interested in knowing if it was technical hurdles or just lack of interest. If technical, could someone please elaborate on what the issues are?



Mike Mezeul



Michael Mezeul

Senior Director R&D

ADVA Optical Networking

2301 North Greenville Avenue, Suite 300

Richardson, TX 75082, USA

Phone: +1.972.759.1216

Fax:     +1.972.759.1201

Mobile: +1.214.448.9239

e-mail: mmezeul <at>



ADVA Optical Networking SE is a European stock corporation ("Societas Europaea") with registered offices at Maerzenquelle 1-3, D-98617 Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr. Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of the Supervisory Board: Anthony Maher * AG Jena HRB 508155 * VAT No. DE 175 446 349



pypy-dev mailing list
pypy-dev <at>