Timothy Baldridge | 25 Oct 00:37 2014

translation error on jit.unroll_safe with jit_libffi

I'm in the process of adding FFI to pixie. It translates and runs fine (I'm sure there's still bugs). But the trace is a bit verbose, so I decided I'd unroll the loop that packs the arguments in the exchange buffer. However then I get this error:

[translation:info]    File "<388-codegen /Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/rtyper.py:540>", line 4, in translate_op_call_args
[translation:info]     return r_arg1.rtype_call_args(hop)
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/rpbc.py", line 659, in rtype_call_args
[translation:info]     return self.redispatch_call(hop, call_args=True)
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/rpbc.py", line 686, in redispatch_call
[translation:info]     hop.llops, hop)
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/rclass.py", line 1075, in rtype_new_instance
[translation:info]     return rinstance.new_instance(llops, classcallhop)
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/rclass.py", line 715, in new_instance
[translation:info]     r.convert_desc_or_const(value))
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/rmodel.py", line 115, in convert_desc_or_const
[translation:info]     return self.convert_const(desc_or_const.value)
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/rtyper/lltypesystem/rpbc.py", line 158, in convert_const
[translation:info]     funcdesc = self.rtyper.annotator.bookkeeper.getdesc(value)
[translation:info]    File "/Users/tim/oss-not-dropbox/externals/pypy/rpython/annotator/bookkeeper.py", line 396, in getdesc
[translation:info]     raise Exception("%s: %r" % (msg, pyobj))
[translation:ERROR] Exception: unexpected prebuilt constant: <staticmethod object at 0x10a8d5bb0>

The line I'm un-commenting is here:

From what I can tell this bug is from the translator trying to do something with the static methods in CallDescr. Why this is happening, I haven't a clue. 

pypy-dev mailing list
pypy-dev <at> python.org
Philip Jenvey | 21 Oct 19:02 2014

PyPy3 2.4.0 released

PyPy3 2.4 - Snow White

We're pleased to announce PyPy3 2.4, which contains significant performance
enhancements and bug fixes.

You can download the PyPy3 2.4.0 release here:


PyPy3 Highlights

Issues reported with our previous release were fixed after reports from users on
our new issue tracker at https://bitbucket.org/pypy/pypy/issues or on IRC at
#pypy. Here is a summary of the user-facing PyPy3 specific changes:

* Better Windows compatibility, e.g. the nt module functions _getfinalpathname
  & _getfileinformation are now supported (the former is required for the
  popular pathlib library for example)

* Various fsencode PEP 383 related fixes to the posix module (readlink, uname,
  ttyname and ctermid) and improved locale handling

* Switched default binary name os POSIX distributions to 'pypy3' (which
  symlinks to to 'pypy3.2')

* Fixed a couple different crashes related to parsing Python 3 source code

Further Highlights (shared w/ PyPy2)

Benchmarks improved after internal enhancements in string and
bytearray handling, and a major rewrite of the GIL handling. This means
that external calls are now a lot faster, especially the CFFI ones. It also
means better performance in a lot of corner cases with handling strings or
bytearrays. The main bugfix is handling of many socket objects in your
program which in the long run used to "leak" memory.

We fixed a memory leak in IO in the sandbox_ code

We welcomed more than 12 new contributors, and conducted two Google
Summer of Code projects, as well as other student projects not
directly related to Summer of Code.

* Reduced internal copying of bytearray operations

* Tweak the internal structure of StringBuilder to speed up large string
  handling, which becomes advantageous on large programs at the cost of slightly
  slower small *benchmark* type programs.

* Boost performance of thread-local variables in both unjitted and jitted code,
  this mostly affects errno handling on linux, which makes external calls

* Move to a mixed polling and mutex GIL model that make mutlithreaded jitted
  code run *much* faster

* Optimize errno handling in linux (x86 and x86-64 only)

* Remove ctypes pythonapi and ctypes.PyDLL, which never worked on PyPy

* Classes in the ast module are now distinct from structures used by
  the compiler, which simplifies and speeds up translation of our
  source code to the PyPy binary interpreter

* Win32 now links statically to zlib, expat, bzip, and openssl-1.0.1i.
  No more missing DLLs

* Many issues were resolved_ since the 2.3.1 release in June

.. _`whats-new`: http://doc.pypy.org/en/latest/whatsnew-2.4.0.html
.. _resolved: https://bitbucket.org/pypy/pypy/issues?status=resolved
.. _sandbox: http://doc.pypy.org/en/latest/sandbox.html

We have further improvements on the way: rpython file handling,
numpy linalg compatibility, as well
as improved GC and many smaller improvements.

Please try it out and let us know what you think. We especially welcome
success stories, we know you are using PyPy, please tell us about it!


The PyPy Team
Valentina Mukhamedzhanova | 19 Oct 22:43 2014

PyPy Warsaw Sprint (October 21-25th, 2014)


I'm in Warsaw these days and I learned that the next PyPy sprint is
taking place here, so I'd like to attend it on October 21st.

I participated in the PyPy sprint at EuroPython this year. I don't
have any specific task to work on, will probably try to fix some
missing 3.3 support.

Timothy Baldridge | 18 Oct 22:08 2014

Weird Unicode errors

My interpreter is built using mostly unicode for symbols and strings, but recently I've been getting some really weird translation errors. The first is this: https://gist.github.com/halgari/0d57dd87434968561705

I tracked this error down to being caused whenever I try an isinstance of unicode like this:

isinstance(x, unicode) 

This is really annoying as I'd love to have a single unified wrap function:

    <at> specialize.argtype(0)
    def wrap(x):
        if isinstance(x, int):
            return numbers.Integer(x)
        if isinstance(x, unicode):
            return String(x)

And as of this morning I started getting errors like this:

[translation:ERROR] TyperError: don't know how to convert from <UnicodeRepr * GcStruct rpy_unicode { hash, chars }> to <UniCharRepr UniChar>
[translation:ERROR] .. (pixie.vm.reader:47)PromptReader.read
[translation:ERROR] .. block <at> 82 with 1 exits
[translation:ERROR] .. v235 = simple_call(v234)

What is a UniChar? My code only deals with unicode strings, so I'm not sure what's happening here. 

Thanks for any help. I've had unicode working perfectly with my interpreter for weeks, and suddenly in the past two days I've started getting these errors. 

pypy-dev mailing list
pypy-dev <at> python.org
Ram Rachum | 18 Oct 18:01 2014

Re: Please update the buildbot

Thanks Matti.

Philip, it looks like our build failed, right?

On Sat, Oct 18, 2014 at 4:11 PM, Matti Picus <matti.picus <at> gmail.com> wrote:

On 18/10/14 04:36, Ram Rachum wrote:
On Sat, Oct 18, 2014 at 12:34 PM, Maciej Fijalkowski <fijall <at> gmail.com <mailto:fijall <at> gmail.com>> wrote:

    both slaves are offline, pester the admins to bring them back (I've no
    clue who, matti maybe?)

    > _______________________________________________
    > pypy-dev mailing list
    > pypy-dev <at> python.org <mailto:pypy-dev <at> python.org>
    > https://mail.python.org/mailman/listinfo/pypy-dev

I restarted the windows buildslave

pypy-dev mailing list
pypy-dev <at> python.org
Philip Jenvey | 16 Oct 21:19 2014

Please update the buildbot

Could someone with access update and cycle the buildbot when they get the chance?


Philip Jenvey
Ram Rachum | 16 Oct 13:11 2014

Py3.3 nightly builds for Windows

Hi guys,

Is there any progress on putting nightly builds of Py3.3 for Windows here:

It has only Linux binaries.

pypy-dev mailing list
pypy-dev <at> python.org
Timothy Baldridge | 14 Oct 16:05 2014

Status of SSE support?

I've read a few older articles about SIMD support in PyPy, what is the status of this? If I wanted to add something like a Vector3 type to my language (like mono did here http://tirania.org/blog/archive/2008/Nov-03.html) and wanted to take advantage of SSE are there primitives for this?



“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)
pypy-dev mailing list
pypy-dev <at> python.org
Armin Rigo | 13 Oct 12:24 2014

Re: [pypy-commit] pypy default: investigate mark_opaque_ptr

Hi Hakan,

On 13 October 2014 11:52, Hakan Ardo <hakan <at> debian.org> wrote:
> On Mon, Oct 13, 2014 at 11:45 AM, Armin Rigo <arigo <at> tunes.org> wrote:
>> Hi Hakan,
>> On 13 October 2014 10:11, Hakan Ardo <hakan <at> debian.org> wrote:
>>> mark_opaque_ptr is used by unrolling to prevent moving getfield_gc(p1)
>>> into the short preamble is p1 if opaque. This is needed since the
>>> pointer might be pointing to something of a different type than what
>>> it was pointing to during the tracing. In which case the execution of
>>> the trace will be aborted before the original position of the
>>> getfield_gc but after the short preamble is executed.
>> Thanks for the confirmation.  This is the only issue, and the only
>> reason for mark_opaque_ptr, right?  I've already written it down in
>> bbebe6918aa9.
> Yes as far as I can remember. You have ofcourse the exact same issue
> with getarrayitem_* and friends...

Ah, indeed.

I'm thinking about a more involved fix, prompted by
https://bitbucket.org/pypy/pypy/issue/1886 .  Would it work?  The idea
would be to allow moving the getfield_gc, but in case it was on an
opaque pointer, add a new "guard_gctype" operation in the short
preamble.  This is possible (and easy) with our own GCs, but wouldn't
work with Boehm, so it would be conditional...


PS: you're still using pypy-dev <at> codespeak.net; I think this address
stopped working by now.  I fixed it to pypy-dev <at> python.org.
Timothy Baldridge | 11 Oct 17:08 2014

GCArray vs list

I'm in the process of tuning my JIT, and thus far it's going pretty well. However I can't mark the args in my Frame object a virtualizable array, because doing so throws this exception: 

[translation:info]    File "/Users/tim/Dropbox/oss/pypy/rpython/jit/metainterp/warmspot.py", line 477, in make_virtualizable_infos
[translation:info]     vinfos[VTYPEPTR] = VirtualizableInfo(self, VTYPEPTR)
[translation:info]    File "/Users/tim/Dropbox/oss/pypy/rpython/jit/metainterp/virtualizable.py", line 52, in __init__
[translation:info]     assert isinstance(ARRAY, lltype.GcArray)

Digging into it I see that ARRAY is: <GcStruct list { length, items }>-- 

That makes me think that there's something I'm doing to my list of args that's flagging it as a list instead of a GcArray? Before I go and rework how args are handled in my interpreter I'd like a bit more information about what could be going on here. 

For the record, I make sure that every access to my args array is inside the valid range of the array, and is always a positive value. I'm then marking it as "args[*]" in my virtualizables. 

If I remove the [*] it translates fine, but then allocates a list on every invocation of an interpreter function. 

Thanks for all the help this far, my interpreter is coming along nicely. 

Timothy Baldridge

pypy-dev mailing list
pypy-dev <at> python.org

GPS vehicle tracker with 3G compatible /Attn: purchase manager与您共享了相册。

邀请您观看 GPS vehicle tracker with 3G compatible /Attn: purchase manager 的相册: GPS vehicle tracker with 3G compatible Attn purchase manager
GPS vehicle tracker with 3G compatible Attn purchase manager
提供者:GPS vehicle tracker with 3G compatible /Attn: purchase manager
来自 GPS vehicle tracker with 3G compatible /Attn: purchase manager 的消息:
Dear Sir

This is Anna,the sales manager of GPS in China.

VT600 is an advanced GPS vehicle tracker, with 3G UMTS 900/2100Mhz or 850/1900Mhz compatible. What is more, VT600 can compatible with accelerator meter to detect harsh start and stop, can compatible with RFID to identify driver, can compatible with camera to take photo. Rich I/O features are available also.

I would appreciate if you forward this letter to Technical Manager or to other expert responsible for technical integration of new products in your company, or provide me with his contact for we could discuss all the details of our future cooperation.

Your early reply is highly appreciated.

Best Regards

要分享您的照片或在朋友与您分享照片时收到通知,请获取属于您自己的免费 Picasa 网络相册帐户
pypy-dev mailing list
pypy-dev <at> python.org