From tbaldridge at gmail.com  Fri Oct  3 05:51:25 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Thu, 2 Oct 2014 21:51:25 -0600
Subject: [pypy-dev] Stacklet problems
Message-ID: <CAL36E+uuiL6Lk+BzLdhtsrYM-4+pO0ACyiCvE5R93h=SREJ8OA@mail.gmail.com>

I have an interpreter that takes advantage of the rstacklet api. My tests
pass fine when running untranslated in CPython, but after translating via
rpython I get a "Segmentation fault: 11", are there any major differences
between cpython and rpython stacklets?

Thanks,

Timothy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141002/5d180dc0/attachment.html>

From tbaldridge at gmail.com  Fri Oct  3 06:09:34 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Thu, 2 Oct 2014 22:09:34 -0600
Subject: [pypy-dev] Stacklet problems
In-Reply-To: <CAL36E+uuiL6Lk+BzLdhtsrYM-4+pO0ACyiCvE5R93h=SREJ8OA@mail.gmail.com>
References: <CAL36E+uuiL6Lk+BzLdhtsrYM-4+pO0ACyiCvE5R93h=SREJ8OA@mail.gmail.com>
Message-ID: <CAL36E+trccNuivosZMoWWSSzHmixjwBWt_wB1c6hs-sLDxqvPw@mail.gmail.com>

For the reference, my interpreter stacklet code is here:

https://github.com/pixie-lang/pixie/blob/master/pixie/vm/stacklet.py

And these tests pass just fine:

https://github.com/pixie-lang/pixie/blob/master/pixie/vm/test/test_stacklet.py

On Thu, Oct 2, 2014 at 9:51 PM, Timothy Baldridge <tbaldridge at gmail.com>
wrote:

> I have an interpreter that takes advantage of the rstacklet api. My tests
> pass fine when running untranslated in CPython, but after translating via
> rpython I get a "Segmentation fault: 11", are there any major differences
> between cpython and rpython stacklets?
>
> Thanks,
>
> Timothy
>
>


-- 
?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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141002/47bac3a0/attachment.html>

From arigo at tunes.org  Sun Oct  5 10:38:17 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 5 Oct 2014 10:38:17 +0200
Subject: [pypy-dev] Stacklet problems
In-Reply-To: <CAL36E+uuiL6Lk+BzLdhtsrYM-4+pO0ACyiCvE5R93h=SREJ8OA@mail.gmail.com>
References: <CAL36E+uuiL6Lk+BzLdhtsrYM-4+pO0ACyiCvE5R93h=SREJ8OA@mail.gmail.com>
Message-ID: <CAMSv6X0Z3DFS=B0yM04+E=xRbgrU_HcVvUbDDjXvp1H9c9D1EQ@mail.gmail.com>

Hi Timothy,

On 3 October 2014 05:51, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> I have an interpreter that takes advantage of the rstacklet api. My tests
> pass fine when running untranslated in CPython, but after translating via
> rpython I get a "Segmentation fault: 11", are there any major differences
> between cpython and rpython stacklets?

I doubt that an unexpected segmentation fault can be resolved with
such vague questions.  Please provide a way for us to reproduce it
(i.e. not a test that passes just fine -- a way to get the segfault)
and then we can start gdb.


A bient?t,

Armin.

From ich at ronnypfannschmidt.de  Sun Oct  5 18:15:12 2014
From: ich at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sun, 05 Oct 2014 18:15:12 +0200
Subject: [pypy-dev] =?iso-8859-1?q?kill_Testrunner_scratchbox_support=3F_?=
	=?iso-8859-1?q?=28arm_develoment=29?=
Message-ID: <bb2686f8-2c24-4641-8dfe-efbf5db1052d@ronnypfannschmidt.de>


Hi,

in the refine-testrunner branch i am currently refactoring
the testrunner to allow easyer reasoning about its code
and support junitxml (for better result metadata than the resultlog format)

While doing so i noticed that we don't seem to use scratchbox anymore,
but (according to a comment from armin on IRC) rather a modern alternative.
So i am wondering if I can maybe scrap the support.

However i would need some help of someone
that handled the current arm setup,
to roughly explain the current setup/needs.

-- Ronny

From exarkun at twistedmatrix.com  Mon Oct  6 01:15:11 2014
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sun, 05 Oct 2014 23:15:11 -0000
Subject: [pypy-dev] cppyy on Ubuntu 14.04
Message-ID: <20141005231511.17800.1068247082.divmod.xquotient.1198@top>

Hello,

I've been looking at cppyy a bit (with the goal of using an existing 
project based on it).  I haven't gotten far though.

When I try to use cppyy with the Ubuntu-packaged PyPy (on Ubuntu 14.04), 
I get this:

  Python 2.7.3 (2.2.1+dfsg-1, Nov 28 2013, 05:13:10)
  [PyPy 2.2.1 with GCC 4.8.2] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  And now for something completely different: ``Is it a cactus bug or 
problem
  with my war?''
  >>>> import cppyy
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ImportError: missing reflection library libcppyy_backend.so
  >>>>
I see that this is a somewhat old version of PyPy - but is that the 
problem?

Thanks,
Jean-Paul

From wlavrijsen at lbl.gov  Mon Oct  6 06:59:40 2014
From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov)
Date: Sun, 5 Oct 2014 21:59:40 -0700 (PDT)
Subject: [pypy-dev] cppyy on Ubuntu 14.04
In-Reply-To: <20141005231511.17800.1068247082.divmod.xquotient.1198@top>
References: <20141005231511.17800.1068247082.divmod.xquotient.1198@top>
Message-ID: <alpine.LSU.2.11.1410052157280.25151@cp3-jyni.yoy.tbi>

Jean-Paul,

> Type "help", "copyright", "credits" or "license" for more information.
> And now for something completely different: ``Is it a cactus bug or problem
> with my war?''
> >>>> import cppyy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ImportError: missing reflection library libcppyy_backend.so
> >>>>
> I see that this is a somewhat old version of PyPy - but is that the problem?

at issue is that cppyy needs to be linked with libReflex.so and since PyPy
builds in all modules, it in turned would need to be linked with that lib.
That would not be good.

So, to work around that, cppyy resolves the methods it needs dynamically, but
it then needs that extra lib. It can be found through here:

   http://doc.pypy.org/en/latest/cppyy.html#installation

HTH,
   Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net

From david.schneider at bivab.de  Mon Oct  6 12:47:41 2014
From: david.schneider at bivab.de (David Schneider)
Date: Mon, 6 Oct 2014 12:47:41 +0200
Subject: [pypy-dev] kill Testrunner scratchbox support? (arm develoment)
In-Reply-To: <bb2686f8-2c24-4641-8dfe-efbf5db1052d@ronnypfannschmidt.de>
References: <bb2686f8-2c24-4641-8dfe-efbf5db1052d@ronnypfannschmidt.de>
Message-ID: <60F4F27C-9263-4351-A750-15799614FFDA@bivab.de>


On 05.10.2014, at 18:15, Ronny Pfannschmidt <ich at ronnypfannschmidt.de> wrote:

> 
> Hi,
> 
> in the refine-testrunner branch i am currently refactoring
> the testrunner to allow easyer reasoning about its code
> and support junitxml (for better result metadata than the resultlog format)
> 
> While doing so i noticed that we don't seem to use scratchbox anymore,
> but (according to a comment from armin on IRC) rather a modern alternative.
> So i am wondering if I can maybe scrap the support.
> 
> However i would need some help of someone
> that handled the current arm setup,
> to roughly explain the current setup/needs.
> 
> -- Ronny
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
Hi Ronny,

the ARM buildbots use scratchbox2 to cross-translate the PyPy binaries for ARM. The tests run natively on ARM hardware and do not use any emulation, so I think it is safe to remove the scratchbox support in the testrunner.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141006/9e234040/attachment.sig>

From exarkun at twistedmatrix.com  Mon Oct  6 13:10:44 2014
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Mon, 06 Oct 2014 11:10:44 -0000
Subject: [pypy-dev] cppyy on Ubuntu 14.04
In-Reply-To: <alpine.LSU.2.11.1410052157280.25151@cp3-jyni.yoy.tbi>
References: <20141005231511.17800.1068247082.divmod.xquotient.1198@top>
 <alpine.LSU.2.11.1410052157280.25151@cp3-jyni.yoy.tbi>
Message-ID: <20141006111044.17800.39254275.divmod.xquotient.1211@top>

On 04:59 am, wlavrijsen at lbl.gov wrote:
>Jean-Paul,
>>Type "help", "copyright", "credits" or "license" for more information.
>>And now for something completely different: ``Is it a cactus bug or 
>>problem
>>with my war?''
>> >>>> import cppyy
>>Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>ImportError: missing reflection library libcppyy_backend.so
>> >>>>
>>I see that this is a somewhat old version of PyPy - but is that the 
>>problem?
>
>at issue is that cppyy needs to be linked with libReflex.so and since 
>PyPy
>builds in all modules, it in turned would need to be linked with that 
>lib.
>That would not be good.
>
>So, to work around that, cppyy resolves the methods it needs 
>dynamically, but
>it then needs that extra lib. It can be found through here:
>
>   http://doc.pypy.org/en/latest/cppyy.html#installation

Hi Wim,

First off, thanks for your work on cppyy.  I don't /like/ having to 
interface with C++ libraries but it's nice to have an option for doing 
so. :)  Thanks for this pointer about this dependency, too.

I've built Reflex and now I can import `cppyy` on PyPy. I had read the 
installation instructions but I don't find it clear from that page that 
building Reflex is a requirement.  It sounds more like Reflex is 
something you need to build if you're building PyPy yourself and want 
the cppyy module.  Maybe that could be clarified on the page.

Also, I wonder if Reflex could turn into a "real" project - or maybe it 
is one already.  Does it have a version control system or issue tracker 
(eg on bitbucket, like PyPy)?  Downloading a source tarball from a user 
directory on a random host makes it look ... fly-by-night?  I'm a little 
worried about building software on this - will it suddenly disappear, is 
there any development activity, etc.

Thanks
>HTH,
>   Wim
>--
>WLavrijsen at lbl.gov    --    +1 (510) 486 6411    -- 
>www.lavrijsen.net

From mail at tsmithe.net  Mon Oct  6 15:15:54 2014
From: mail at tsmithe.net (Toby St Clere Smithe)
Date: Mon, 06 Oct 2014 15:15:54 +0200
Subject: [pypy-dev] cppyy on Ubuntu 14.04
References: <20141005231511.17800.1068247082.divmod.xquotient.1198@top>
 <alpine.LSU.2.11.1410052157280.25151@cp3-jyni.yoy.tbi>
 <20141006111044.17800.39254275.divmod.xquotient.1211@top>
Message-ID: <8738b1s5it.fsf@tsmithe.net>

Hi all,

exarkun at twistedmatrix.com writes:
> Also, I wonder if Reflex could turn into a "real" project - or maybe
> it is one already.  Does it have a version control system or issue
> tracker (eg on bitbucket, like PyPy)?  Downloading a source tarball
> from a user directory on a random host makes it look ... fly-by-night?
> I'm a little worried about building software on this - will it
> suddenly disappear, is there any development activity, etc.

I've been thinking about this. Reflex is part of ROOT[1], so I think it
does count as a 'real project'; Wim will clarify, I'm sure. But my
thinking is as follows: currently, it is hard to build an extension
using a C++ library for both CPython and PyPy. Reflex makes this easier,
but it is only available on CPython via PyCintex, which means (I think)
you need to build ROOT, or at least dig into the ROOT build system,
which is not particularly convenient.

Currently, I have a CPython extension that uses Boost.Python, and I
would like to find a Python-C-API-agnostic way of wrapping it. Reflex
would seem to be a good step in that direction, but it is a shame that
it and PyCintex are (it seems) rather locked into ROOT. It would be
great if -- like the Reflex tarball distributed for use with cppyy --
these bits could all be distributed and built separately, so that
building portable C++ extensions could be a lot easier, and that this
could be done widely.

Right now it would be very hard for me to switch from boost.python,
because it is very easy to build and distribute extensions using
boost.python, without requiring the user has complex dependencies
installed.

[1] http://root.cern.ch/drupal/content/reflex

Cheers,

Toby

-- 
Toby St Clere Smithe
http://tsmithe.net


From fijall at gmail.com  Mon Oct  6 19:22:01 2014
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 6 Oct 2014 19:22:01 +0200
Subject: [pypy-dev] kill Testrunner scratchbox support? (arm develoment)
In-Reply-To: <60F4F27C-9263-4351-A750-15799614FFDA@bivab.de>
References: <bb2686f8-2c24-4641-8dfe-efbf5db1052d@ronnypfannschmidt.de>
 <60F4F27C-9263-4351-A750-15799614FFDA@bivab.de>
Message-ID: <CAK5idxTC35O+8O0S0e5U5w_w9jnx3obb09Fg=w=6pcXCoHV5xg@mail.gmail.com>

Are you really winning anything with that kill? If you want to kill it
just to kill it please don't, we might want to use it in the future

On Mon, Oct 6, 2014 at 12:47 PM, David Schneider
<david.schneider at bivab.de> wrote:
>
> On 05.10.2014, at 18:15, Ronny Pfannschmidt <ich at ronnypfannschmidt.de> wrote:
>
>>
>> Hi,
>>
>> in the refine-testrunner branch i am currently refactoring
>> the testrunner to allow easyer reasoning about its code
>> and support junitxml (for better result metadata than the resultlog format)
>>
>> While doing so i noticed that we don't seem to use scratchbox anymore,
>> but (according to a comment from armin on IRC) rather a modern alternative.
>> So i am wondering if I can maybe scrap the support.
>>
>> However i would need some help of someone
>> that handled the current arm setup,
>> to roughly explain the current setup/needs.
>>
>> -- Ronny
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
> Hi Ronny,
>
> the ARM buildbots use scratchbox2 to cross-translate the PyPy binaries for ARM. The tests run natively on ARM hardware and do not use any emulation, so I think it is safe to remove the scratchbox support in the testrunner.
>
> David
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From wlavrijsen at lbl.gov  Mon Oct  6 19:43:01 2014
From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov)
Date: Mon, 6 Oct 2014 10:43:01 -0700 (PDT)
Subject: [pypy-dev] cppyy on Ubuntu 14.04
In-Reply-To: <20141006111044.17800.39254275.divmod.xquotient.1211@top>
References: <20141005231511.17800.1068247082.divmod.xquotient.1198@top>
 <alpine.LSU.2.11.1410052157280.25151@cp3-jyni.yoy.tbi>
 <20141006111044.17800.39254275.divmod.xquotient.1211@top>
Message-ID: <alpine.LSU.2.11.1410061016220.23815@cp3-jyni.yoy.tbi>

Jean-Paul,

to follow-up on what Toby already said ...

For us it's not so much differences between CPython and PyPy (there is cpyext,
after all). Even with CPython one has to deal with different Python versions,
and Reflex let's one get away from that.

The larger point is scaling. The idea behind something like SWIG (or even CFFI),
is that the authors of their own packages use it, and can customize it as needed
(because they are willing and able to do so). We OTOH need to throw a couple of
million lines of code at it, with no author support, and also have it all work
seamlessly. Full automation is then the only way to go.

Yes, Reflex is mature and supported, but part of ROOT, and not packaged
independently (other than the tar ball that the instructions point at). With
PyCintex.py (now called cppyy.py) it's even worse as it requires certain ROOT
libraries. Reflex is no longer developed, however.

(For bugs and other support, root.cern.ch is available.)

What we are working on is Cling (http://root.cern.ch/drupal/content/cling), which
is also mature and supported, but beyond that, it is actively being developed.
The benefits are support for C++14, and it being a true C++ compiler can munch
pretty much anything you throw at it, including massively templated boost headers
(there's a caveat for inline asm, which doesn't work, the rest is fine).

All our cycles, however, are being soaked up by migrating legacy C++ codes that
made use of the Reflex (and other deprecated) APIs directly. A lot of that code
is orphaned (no docs, tests, and authors unreachable). In ATLAS, we had two guys
working on that, but both have left, so I got pulled into that. Until the fog
clears on that account, there's little I can do to reduce dependencies and
repackage, simply due to lack of time.

But hey, it's all open source and the most restrictive license you'll run into
is LGPL (for ROOT code; the python bits can be made available under modified BSD).
So, if anyone does have spare cycles, they're more than welcome to contribute.

Best regards,
            Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net

From infoin9 at grr.zyoux.com  Wed Oct  8 06:38:02 2014
From: infoin9 at grr.zyoux.com (GPS vehicle tracker with 3G compatible /Attn: purchase manager)
Date: Wed, 08 Oct 2014 04:38:02 +0000
Subject: [pypy-dev] =?gb2312?b?R1BTIHZlaGljbGUgIHRyYWNrZXIgIHdpdGggM0cg?=
	=?gb2312?b?Y29tcGF0aWJsZSAgL0F0dG46IHB1cmNoYXNlIG1hbmFnZXLT68T6?=
	=?gb2312?b?ubLP7cHLz+Cy4aGj?=
Message-ID: <f46d04478c3d9454a60504e1e1d6@google.com>

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

Anna

https://picasaweb.google.com/lh/sredir?uname=113068216911443794145&target=ALBUM&id=6033753611831948289&authkey=Gv1sRgCMn98ZL9nsTXCg&invite=CLiWw9EG&feat=email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141008/962aee7f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picasaweblogo-zh_CN.gif
Type: image/gif
Size: 1646 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141008/962aee7f/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.jpg
Type: image/jpeg
Size: 3826 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141008/962aee7f/attachment.jpg>

From tbaldridge at gmail.com  Sat Oct 11 17:08:16 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Sat, 11 Oct 2014 09:08:16 -0600
Subject: [pypy-dev] GCArray vs list
Message-ID: <CAL36E+tSSbKEFYxApC4sp08LbEFpmC_L+uok0TcrKhcP2rTPSw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141011/a21f1443/attachment.html>

From alex.gaynor at gmail.com  Sat Oct 11 17:14:51 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Sat, 11 Oct 2014 08:14:51 -0700
Subject: [pypy-dev] GCArray vs list
In-Reply-To: <CAL36E+tSSbKEFYxApC4sp08LbEFpmC_L+uok0TcrKhcP2rTPSw@mail.gmail.com>
References: <CAL36E+tSSbKEFYxApC4sp08LbEFpmC_L+uok0TcrKhcP2rTPSw@mail.gmail.com>
Message-ID: <CAFRnB2UzG+2VLJzM_oVGZtX4tj6G4m-HO1raxPrTWGRyjuGUrg@mail.gmail.com>

Lists are resizable, GcArray are not. A Python "list" object will become a
GcArray automatically if you never call a method that can resize it, such
as append. Basically for it to be a GcArray you should allocate it with
[None] * n, and then only use __setitem__ and __getitem__.

Cheers,
Alex

On Sat, Oct 11, 2014 at 8:08 AM, Timothy Baldridge <tbaldridge at gmail.com>
wrote:

> 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
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141011/43b971ce/attachment.html>

From tbaldridge at gmail.com  Sat Oct 11 17:18:37 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Sat, 11 Oct 2014 09:18:37 -0600
Subject: [pypy-dev] GCArray vs list
In-Reply-To: <CAFRnB2UzG+2VLJzM_oVGZtX4tj6G4m-HO1raxPrTWGRyjuGUrg@mail.gmail.com>
References: <CAL36E+tSSbKEFYxApC4sp08LbEFpmC_L+uok0TcrKhcP2rTPSw@mail.gmail.com>
 <CAFRnB2UzG+2VLJzM_oVGZtX4tj6G4m-HO1raxPrTWGRyjuGUrg@mail.gmail.com>
Message-ID: <CAL36E+ukFtrrXiAaYKZDX0uLb+m=5hskHCdP_tfXr418aWrFow@mail.gmail.com>

Awesome, thanks, that's exactly what I was thinking. I'll audit my code for
such usages and see if that helps.

Timothy

On Sat, Oct 11, 2014 at 9:14 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Lists are resizable, GcArray are not. A Python "list" object will become a
> GcArray automatically if you never call a method that can resize it, such
> as append. Basically for it to be a GcArray you should allocate it with
> [None] * n, and then only use __setitem__ and __getitem__.
>
> Cheers,
> Alex
>
> On Sat, Oct 11, 2014 at 8:08 AM, Timothy Baldridge <tbaldridge at gmail.com>
> wrote:
>
>> 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
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>



-- 
?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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141011/a36b1a37/attachment.html>

From arigo at tunes.org  Sat Oct 11 22:55:25 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 11 Oct 2014 22:55:25 +0200
Subject: [pypy-dev] GCArray vs list
In-Reply-To: <CAL36E+ukFtrrXiAaYKZDX0uLb+m=5hskHCdP_tfXr418aWrFow@mail.gmail.com>
References: <CAL36E+tSSbKEFYxApC4sp08LbEFpmC_L+uok0TcrKhcP2rTPSw@mail.gmail.com>
 <CAFRnB2UzG+2VLJzM_oVGZtX4tj6G4m-HO1raxPrTWGRyjuGUrg@mail.gmail.com>
 <CAL36E+ukFtrrXiAaYKZDX0uLb+m=5hskHCdP_tfXr418aWrFow@mail.gmail.com>
Message-ID: <CAMSv6X0NMiOvWvZfLP+Q+5AAux9WUX6wey0WGLPm00zJ-ab3Jg@mail.gmail.com>

Hi Timothy,

On 11 October 2014 17:18, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> Awesome, thanks, that's exactly what I was thinking. I'll audit my code for
> such usages and see if that helps.

An automated way to do that is to use
rpython.rlib.debug.make_sure_not_resized() on the frame's attribute.
Maybe we should automatically add such a call early, for any list in
_virtualizable_, instead of crashing later as you reported.


A bient?t,

Armin.

From arigo at tunes.org  Mon Oct 13 12:24:21 2014
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 13 Oct 2014 12:24:21 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
Message-ID: <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>

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...


Armin

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.

From hakan at debian.org  Mon Oct 13 13:10:01 2014
From: hakan at debian.org (Hakan Ardo)
Date: Mon, 13 Oct 2014 13:10:01 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
 <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
Message-ID: <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>

On Mon, Oct 13, 2014 at 12:24 PM, Armin Rigo <arigo at tunes.org> wrote:
>>
>> 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...

Maybe. I cant see why not. If the opaque pointer shows up in the
VirtualState there might be some similar fixes needed there. I.e.
there is probably cases where VirtualState.generate_guards needs to
generate a guard_gctype aswell.

I think the problematic case is actually when mixing with arrays.
There will already be a guard_class protecting the getfiled in the
short preamble, but it crashes when operating on an array. Also, there
is no guard_arraytype. So mixing different types of arrays will crash.
There is logic to generate guards for the arraylen and place those in
short preamble.

>
> 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.

Sorry (I got no bounce though).

-- 
H?kan Ard?

From arigo at tunes.org  Mon Oct 13 18:09:32 2014
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 13 Oct 2014 18:09:32 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
 <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
 <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>
Message-ID: <CAMSv6X3U51o2MhjF3PV=AJcinED63Ox0L33zWZExfd66GmSLfg@mail.gmail.com>

Hi Hakan,

On 13 October 2014 13:10, Hakan Ardo <hakan at debian.org> wrote:
> I think the problematic case is actually when mixing with arrays.
> There will already be a guard_class protecting the getfiled in the
> short preamble, but it crashes when operating on an array. Also, there
> is no guard_arraytype. So mixing different types of arrays will crash.
> There is logic to generate guards for the arraylen and place those in
> short preamble.

I think it should work.  What I have in mind for GUARD_GCTYPE would be
to check the GC header of the object; all GC pointers have one, with
our own GCs --- even GcArrays.  So GUARD_GCTYPE would check that the
object is exactly of the correct type: the right kind of GcArray, or
the right kind of GcStruct that is not necessarily an RPython
instance.  It would be inserted before we do more checks with that
pointer, whenever the pointer may originally be opaque.

Btw, a GUARD_CLASS on an opaque pointer that is not actually an
RPython instance may also crash, depending on the translation
settings.  I think it works without problem if "gcremovetypeptr" is
True (the default on 64-bit, but not on 32-bit).  If it is False, then
we have a very unlikely but possible false positive where the check is
done by reading the 2nd word of the object, just after the GC header,
and checking that it is exactly some value.  If the object is
actually, say, a tuple of integers, then it would be possible that the
first integer has exactly the same value as expected.  So unless I'm
missing something else, we have a potential bug that involves creating
a range(a, b, c) with a being exactly the same as the address of some
vtable thing...

This would also be resolved if in this case we put a GUARD_GCTYPE
first (and then don't need an additional GUARD_CLASS).


A bient?t,

Armin.

From hakan at debian.org  Mon Oct 13 18:59:25 2014
From: hakan at debian.org (Hakan Ardo)
Date: Mon, 13 Oct 2014 18:59:25 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAMSv6X3U51o2MhjF3PV=AJcinED63Ox0L33zWZExfd66GmSLfg@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
 <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
 <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>
 <CAMSv6X3U51o2MhjF3PV=AJcinED63Ox0L33zWZExfd66GmSLfg@mail.gmail.com>
Message-ID: <CAEkL+Rgq3L_cAhmpM1Zkk1UqjYdcSMn=OY=duXDy9_nTodHsug@mail.gmail.com>

On Mon, Oct 13, 2014 at 6:09 PM, Armin Rigo <arigo at tunes.org> wrote:
>
> I think it should work.

I'm sure your right :)

> What I have in mind for GUARD_GCTYPE would be
> to check the GC header of the object; all GC pointers have one, with
> our own GCs --- even GcArrays.  So GUARD_GCTYPE would check that the
> object is exactly of the correct type: the right kind of GcArray, or
> the right kind of GcStruct that is not necessarily an RPython
> instance.  It would be inserted before we do more checks with that
> pointer, whenever the pointer may originally be opaque.

Are we certain opaque pointers always refer to GC-objects?

>
> Btw, a GUARD_CLASS on an opaque pointer that is not actually an
> RPython instance may also crash, depending on the translation
> settings.  I think it works without problem if "gcremovetypeptr" is
> True (the default on 64-bit, but not on 32-bit).  If it is False, then
> we have a very unlikely but possible false positive where the check is
> done by reading the 2nd word of the object, just after the GC header,
> and checking that it is exactly some value.  If the object is
> actually, say, a tuple of integers, then it would be possible that the
> first integer has exactly the same value as expected.  So unless I'm
> missing something else, we have a potential bug that involves creating
> a range(a, b, c) with a being exactly the same as the address of some
> vtable thing...

Right, but mark_opaque_ptr prevents this case as well by not moving
operations using opaque pointers into the short preamble. So I guess
we are currently fine?


-- 
H?kan Ard?

From arigo at tunes.org  Tue Oct 14 09:26:10 2014
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 14 Oct 2014 09:26:10 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAEkL+Rgq3L_cAhmpM1Zkk1UqjYdcSMn=OY=duXDy9_nTodHsug@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
 <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
 <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>
 <CAMSv6X3U51o2MhjF3PV=AJcinED63Ox0L33zWZExfd66GmSLfg@mail.gmail.com>
 <CAEkL+Rgq3L_cAhmpM1Zkk1UqjYdcSMn=OY=duXDy9_nTodHsug@mail.gmail.com>
Message-ID: <CAMSv6X3okxK2rOJBCcNxzWA1LEt_6yz2HFhbwPb4_JC1qhxEdw@mail.gmail.com>

Hi Hakan,

On 13 October 2014 18:59, Hakan Ardo <hakan at debian.org> wrote:
> Are we certain opaque pointers always refer to GC-objects?

Yes.

> Right, but mark_opaque_ptr prevents this case as well by not moving
> operations using opaque pointers into the short preamble. So I guess
> we are currently fine?

I'm not sure: the logic in optimizeopt/heap.py seems to be "if it's an
opaque pointer, and if we don't know its class, then don't move it".
According to this logic, operations on RPython instances (like
GUARD_CLASS) can still be moved to the short preamble.  Maybe I'm
missing something else?


A bient?t,

Armin.

From hakan at debian.org  Tue Oct 14 09:55:16 2014
From: hakan at debian.org (Hakan Ardo)
Date: Tue, 14 Oct 2014 09:55:16 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAMSv6X3okxK2rOJBCcNxzWA1LEt_6yz2HFhbwPb4_JC1qhxEdw@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
 <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
 <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>
 <CAMSv6X3U51o2MhjF3PV=AJcinED63Ox0L33zWZExfd66GmSLfg@mail.gmail.com>
 <CAEkL+Rgq3L_cAhmpM1Zkk1UqjYdcSMn=OY=duXDy9_nTodHsug@mail.gmail.com>
 <CAMSv6X3okxK2rOJBCcNxzWA1LEt_6yz2HFhbwPb4_JC1qhxEdw@mail.gmail.com>
Message-ID: <CAEkL+RhnsEs7yeOshhy-rBjYBmzpPmr0YBZ6=fvHhViOMmT0Ag@mail.gmail.com>

On Tue, Oct 14, 2014 at 9:26 AM, Armin Rigo <arigo at tunes.org> wrote:
>
> I'm not sure: the logic in optimizeopt/heap.py seems to be "if it's an
> opaque pointer, and if we don't know its class, then don't move it".
> According to this logic, operations on RPython instances (like
> GUARD_CLASS) can still be moved to the short preamble.  Maybe I'm
> missing something else?

I see. Yes, there is the logic of ShortBoxes.assumed_classes which is
supposed to make sure never to inline a short_preamble in cases where
the class of the opaque pointer is not already known. This logic could
probably be killed with your solution.

-- 
H?kan Ard?

From tbaldridge at gmail.com  Tue Oct 14 16:05:38 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Tue, 14 Oct 2014 08:05:38 -0600
Subject: [pypy-dev] Status of SSE support?
Message-ID: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>

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?

Thanks,

Timothy

-- 
?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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141014/2ad9c1f3/attachment.html>

From alex.gaynor at gmail.com  Tue Oct 14 16:15:48 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 14 Oct 2014 07:15:48 -0700
Subject: [pypy-dev] Status of SSE support?
In-Reply-To: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
References: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
Message-ID: <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>

There aren't any primitives for this right now, no. I'd say it would be
medium level of difficult to add support to the JIT for this, probably a
day of work for someone who knew the codebase, a few days for someone
learning it.

On Tue, Oct 14, 2014 at 7:05 AM, Timothy Baldridge <tbaldridge at gmail.com>
wrote:

> 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?
>
> Thanks,
>
> Timothy
>
> --
> ?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
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141014/45f281ee/attachment.html>

From fijall at gmail.com  Tue Oct 14 18:41:10 2014
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 14 Oct 2014 18:41:10 +0200
Subject: [pypy-dev] Status of SSE support?
In-Reply-To: <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>
References: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
 <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>
Message-ID: <CAK5idxS8n1hnj9O7v1yyR+2T07G_y9gJnmHMPD56Mvww8eJ-5Q@mail.gmail.com>

i would say a bit more than that :-)

On Tue, Oct 14, 2014 at 4:15 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> There aren't any primitives for this right now, no. I'd say it would be
> medium level of difficult to add support to the JIT for this, probably a day
> of work for someone who knew the codebase, a few days for someone learning
> it.
>
> On Tue, Oct 14, 2014 at 7:05 AM, Timothy Baldridge <tbaldridge at gmail.com>
> wrote:
>>
>> 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?
>>
>> Thanks,
>>
>> Timothy
>>
>> --
>> ?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
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From alex.gaynor at gmail.com  Tue Oct 14 18:42:15 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 14 Oct 2014 09:42:15 -0700
Subject: [pypy-dev] Status of SSE support?
In-Reply-To: <CAK5idxS8n1hnj9O7v1yyR+2T07G_y9gJnmHMPD56Mvww8eJ-5Q@mail.gmail.com>
References: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
 <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>
 <CAK5idxS8n1hnj9O7v1yyR+2T07G_y9gJnmHMPD56Mvww8eJ-5Q@mail.gmail.com>
Message-ID: <CAFRnB2U1hdYd21TQsdyzV3eogiu1z9Mn1sCby8w=xFFX3gvgUw@mail.gmail.com>

I'm talking about an explicit "vector_3f_add()" primitive, would be pretty
straightforward to do the mapping. IIRC it took us less than a day to add
READ_TIMESTAMP instruction.

Alex

On Tue, Oct 14, 2014 at 9:41 AM, Maciej Fijalkowski <fijall at gmail.com>
wrote:

> i would say a bit more than that :-)
>
> On Tue, Oct 14, 2014 at 4:15 PM, Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
> > There aren't any primitives for this right now, no. I'd say it would be
> > medium level of difficult to add support to the JIT for this, probably a
> day
> > of work for someone who knew the codebase, a few days for someone
> learning
> > it.
> >
> > On Tue, Oct 14, 2014 at 7:05 AM, Timothy Baldridge <tbaldridge at gmail.com
> >
> > wrote:
> >>
> >> 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?
> >>
> >> Thanks,
> >>
> >> Timothy
> >>
> >> --
> >> ?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
> >> https://mail.python.org/mailman/listinfo/pypy-dev
> >>
> >
> >
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right
> to
> > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > "The people's good is the highest law." -- Cicero
> > GPG Key fingerprint: 125F 5C67 DFE9 4084
> >
> > _______________________________________________
> > pypy-dev mailing list
> > pypy-dev at python.org
> > https://mail.python.org/mailman/listinfo/pypy-dev
> >
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141014/b761fe91/attachment.html>

From fijall at gmail.com  Tue Oct 14 18:45:03 2014
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 14 Oct 2014 18:45:03 +0200
Subject: [pypy-dev] Status of SSE support?
In-Reply-To: <CAFRnB2U1hdYd21TQsdyzV3eogiu1z9Mn1sCby8w=xFFX3gvgUw@mail.gmail.com>
References: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
 <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>
 <CAK5idxS8n1hnj9O7v1yyR+2T07G_y9gJnmHMPD56Mvww8eJ-5Q@mail.gmail.com>
 <CAFRnB2U1hdYd21TQsdyzV3eogiu1z9Mn1sCby8w=xFFX3gvgUw@mail.gmail.com>
Message-ID: <CAK5idxSVuYHq15Oro84fpPL62utCxU6GY+q565=GTZ5VB2JWww@mail.gmail.com>

I think that part can be resurrected from some branch, I added it at
some point. The problem is that you need aligned data access and the
responsibility is on the user of this primitive

On Tue, Oct 14, 2014 at 6:42 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> I'm talking about an explicit "vector_3f_add()" primitive, would be pretty
> straightforward to do the mapping. IIRC it took us less than a day to add
> READ_TIMESTAMP instruction.
>
> Alex
>
> On Tue, Oct 14, 2014 at 9:41 AM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
>>
>> i would say a bit more than that :-)
>>
>> On Tue, Oct 14, 2014 at 4:15 PM, Alex Gaynor <alex.gaynor at gmail.com>
>> wrote:
>> > There aren't any primitives for this right now, no. I'd say it would be
>> > medium level of difficult to add support to the JIT for this, probably a
>> > day
>> > of work for someone who knew the codebase, a few days for someone
>> > learning
>> > it.
>> >
>> > On Tue, Oct 14, 2014 at 7:05 AM, Timothy Baldridge
>> > <tbaldridge at gmail.com>
>> > wrote:
>> >>
>> >> 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?
>> >>
>> >> Thanks,
>> >>
>> >> Timothy
>> >>
>> >> --
>> >> ?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
>> >> https://mail.python.org/mailman/listinfo/pypy-dev
>> >>
>> >
>> >
>> >
>> > --
>> > "I disapprove of what you say, but I will defend to the death your right
>> > to
>> > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> > "The people's good is the highest law." -- Cicero
>> > GPG Key fingerprint: 125F 5C67 DFE9 4084
>> >
>> > _______________________________________________
>> > pypy-dev mailing list
>> > pypy-dev at python.org
>> > https://mail.python.org/mailman/listinfo/pypy-dev
>> >
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084

From arigo at tunes.org  Tue Oct 14 18:46:25 2014
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 14 Oct 2014 18:46:25 +0200
Subject: [pypy-dev] Status of SSE support?
In-Reply-To: <CAFRnB2U1hdYd21TQsdyzV3eogiu1z9Mn1sCby8w=xFFX3gvgUw@mail.gmail.com>
References: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
 <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>
 <CAK5idxS8n1hnj9O7v1yyR+2T07G_y9gJnmHMPD56Mvww8eJ-5Q@mail.gmail.com>
 <CAFRnB2U1hdYd21TQsdyzV3eogiu1z9Mn1sCby8w=xFFX3gvgUw@mail.gmail.com>
Message-ID: <CAMSv6X1os=ogZXD7Z2LVTuXj7d8qZPkVjKBH1QaVr_wN65zO3w@mail.gmail.com>

Hi Alex,

On 14 October 2014 18:42, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> I'm talking about an explicit "vector_3f_add()" primitive, would be pretty
> straightforward to do the mapping. IIRC it took us less than a day to add
> READ_TIMESTAMP instruction.

I agree with Maciej on this point.  The problem with "vector_3f_add()"
is that it needs to use more than the lower 8 bytes of xmm registers.
We currently have no support for
initializing/allocating/saving/restoring such special xmm registers.
The alternative would be to have a "vector_3f_add()" that takes 4 xmm
registers, combine them into two, add them, and re-split the result.
It's unclear if that's really faster than doing two separate additions
though.


A bient?t,

Armin.

From arigo at tunes.org  Tue Oct 14 18:48:59 2014
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 14 Oct 2014 18:48:59 +0200
Subject: [pypy-dev] Status of SSE support?
In-Reply-To: <CAMSv6X1os=ogZXD7Z2LVTuXj7d8qZPkVjKBH1QaVr_wN65zO3w@mail.gmail.com>
References: <CAL36E+vDqcEVOWEgcSys36Uh5GE5A5NRXs2qHvgg3Ei_hSsutw@mail.gmail.com>
 <CAFRnB2XbFHt6V0oKw7Y3m-27XYs4dtTSF9j=kO9tu_Ln-03hEA@mail.gmail.com>
 <CAK5idxS8n1hnj9O7v1yyR+2T07G_y9gJnmHMPD56Mvww8eJ-5Q@mail.gmail.com>
 <CAFRnB2U1hdYd21TQsdyzV3eogiu1z9Mn1sCby8w=xFFX3gvgUw@mail.gmail.com>
 <CAMSv6X1os=ogZXD7Z2LVTuXj7d8qZPkVjKBH1QaVr_wN65zO3w@mail.gmail.com>
Message-ID: <CAMSv6X3wBiRYCnn7UnJ7t50mZpo+cA7ePoF9zhFL=rf45APCmw@mail.gmail.com>

On 14 October 2014 18:46, Armin Rigo <arigo at tunes.org> wrote:
> The alternative would be to have a "vector_3f_add()" that takes 4 xmm
> registers, combine them into two, add them, and re-split the result.

...or, as Maciej says, have only the ability to operate on memory
data.  But even ignoring the alignment mess, that's even worse in this
case, because what you have here is vectors of 3 numbers, not big
arrays of numbers.


A bient?t,

Armin.

From hakan at debian.org  Tue Oct 14 19:04:55 2014
From: hakan at debian.org (Hakan Ardo)
Date: Tue, 14 Oct 2014 19:04:55 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: investigate
	mark_opaque_ptr
In-Reply-To: <CAEkL+RhnsEs7yeOshhy-rBjYBmzpPmr0YBZ6=fvHhViOMmT0Ag@mail.gmail.com>
References: <20141013075934.D169B1D22C4@cobra.cs.uni-duesseldorf.de>
 <CAEkL+RgZr=4rrpsEVHVDj_BFBX7QMB+8raYXdUjzw+Ex1uim1w@mail.gmail.com>
 <CAMSv6X2Vi7KWOewqJ8B2T=5y_AZn2qVj2Wu9nV5HFg556VRSTA@mail.gmail.com>
 <CAEkL+RjdP2f78iqsnJ+TepOGcVd2yHGv7uv1qmQrn48bJnXkoA@mail.gmail.com>
 <CAMSv6X2u69qK49e=NYytZ-V1ywue8qad5fTxYapUrKuAqcdc5g@mail.gmail.com>
 <CAEkL+RgBbVyRUNM6+6q1rkYYcswLR1tX-S+qY6qa6W79iHHGpg@mail.gmail.com>
 <CAMSv6X3U51o2MhjF3PV=AJcinED63Ox0L33zWZExfd66GmSLfg@mail.gmail.com>
 <CAEkL+Rgq3L_cAhmpM1Zkk1UqjYdcSMn=OY=duXDy9_nTodHsug@mail.gmail.com>
 <CAMSv6X3okxK2rOJBCcNxzWA1LEt_6yz2HFhbwPb4_JC1qhxEdw@mail.gmail.com>
 <CAEkL+RhnsEs7yeOshhy-rBjYBmzpPmr0YBZ6=fvHhViOMmT0Ag@mail.gmail.com>
Message-ID: <CAEkL+Rju+c44hhSqTJPYqGKoNaxsxeyiE2AJAF+pHXeSUwPqPg@mail.gmail.com>

Hi again,
for more details, look at  77dce024e344. It takes the original
approach of not touching operations using opaque pointers at all into
one that allows getfield_gc(p,...) with p opaque in the short_preamble
in some specific cases.

On Tue, Oct 14, 2014 at 9:55 AM, Hakan Ardo <hakan at debian.org> wrote:
> On Tue, Oct 14, 2014 at 9:26 AM, Armin Rigo <arigo at tunes.org> wrote:
>>
>> I'm not sure: the logic in optimizeopt/heap.py seems to be "if it's an
>> opaque pointer, and if we don't know its class, then don't move it".
>> According to this logic, operations on RPython instances (like
>> GUARD_CLASS) can still be moved to the short preamble.  Maybe I'm
>> missing something else?
>
> I see. Yes, there is the logic of ShortBoxes.assumed_classes which is
> supposed to make sure never to inline a short_preamble in cases where
> the class of the opaque pointer is not already known. This logic could
> probably be killed with your solution.
>
> --
> H?kan Ard?



-- 
H?kan Ard?

From ram at rachum.com  Thu Oct 16 13:11:53 2014
From: ram at rachum.com (Ram Rachum)
Date: Thu, 16 Oct 2014 14:11:53 +0300
Subject: [pypy-dev] Py3.3 nightly builds for Windows
Message-ID: <CANXboVaioQ58ysKbnr36o_5HvP42_jQOyoJyhZBK41ApOMGmWQ@mail.gmail.com>

Hi guys,

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

http://buildbot.pypy.org/nightly/py3.3/

It has only Linux binaries.


Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141016/13c8a16e/attachment.html>

From pjenvey at underboss.org  Thu Oct 16 21:18:54 2014
From: pjenvey at underboss.org (Philip Jenvey)
Date: Thu, 16 Oct 2014 12:18:54 -0700
Subject: [pypy-dev] Py3.3 nightly builds for Windows
In-Reply-To: <CANXboVaioQ58ysKbnr36o_5HvP42_jQOyoJyhZBK41ApOMGmWQ@mail.gmail.com>
References: <CANXboVaioQ58ysKbnr36o_5HvP42_jQOyoJyhZBK41ApOMGmWQ@mail.gmail.com>
Message-ID: <1F5050D6-DAEF-41A7-947A-DC5B00518634@underboss.org>


On Oct 16, 2014, at 4:11 AM, Ram Rachum <ram at rachum.com> wrote:

> Hi guys,
> 
> Is there any progress on putting nightly builds of Py3.3 for Windows here:
> 
> http://buildbot.pypy.org/nightly/py3.3/
> 
> It has only Linux binaries.

Hey Ram,

For py3: we are not currently building nightlies for the py3.3 branch and only build them for the py3k branch on linux64. We should probably change this going forward.

In the meantime, you can actually trigger a build on your own from a builder page such as this one:

http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32

(just put your name in the field)

I went ahead and just triggered a Windows build for py3.3. Though I'll admit that I?m not sure if it will even translate, we?ll see =]

--
Philip Jenvey


From pjenvey at underboss.org  Thu Oct 16 21:19:57 2014
From: pjenvey at underboss.org (Philip Jenvey)
Date: Thu, 16 Oct 2014 12:19:57 -0700
Subject: [pypy-dev] Please update the buildbot
Message-ID: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>

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

Thanks,

--
Philip Jenvey


From arigo at tunes.org  Sat Oct 18 08:19:56 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 18 Oct 2014 08:19:56 +0200
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
Message-ID: <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>

Hi Philip,

On 16 October 2014 21:19, Philip Jenvey <pjenvey at underboss.org> wrote:
> Could someone with access update and cycle the buildbot when they get the chance?

Updated it one or two days ago.  It is at current tip (a768fa781d1b).


Armin

From ram at rachum.com  Sat Oct 18 11:30:32 2014
From: ram at rachum.com (Ram Rachum)
Date: Sat, 18 Oct 2014 12:30:32 +0300
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
Message-ID: <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>

Armin: I don't understand how buildbots work too well, but on this page:

http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32

It seems that Philip scheduled a build 38 hours ago and it hasn't started.
We want it to be built.

On Sat, Oct 18, 2014 at 9:19 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Philip,
>
> On 16 October 2014 21:19, Philip Jenvey <pjenvey at underboss.org> wrote:
> > Could someone with access update and cycle the buildbot when they get
> the chance?
>
> Updated it one or two days ago.  It is at current tip (a768fa781d1b).
>
>
> Armin
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/938e089b/attachment.html>

From fijall at gmail.com  Sat Oct 18 11:34:50 2014
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 18 Oct 2014 11:34:50 +0200
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
Message-ID: <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>

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

On Sat, Oct 18, 2014 at 11:30 AM, Ram Rachum <ram at rachum.com> wrote:
> Armin: I don't understand how buildbots work too well, but on this page:
>
> http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32
>
> It seems that Philip scheduled a build 38 hours ago and it hasn't started.
> We want it to be built.
>
> On Sat, Oct 18, 2014 at 9:19 AM, Armin Rigo <arigo at tunes.org> wrote:
>>
>> Hi Philip,
>>
>> On 16 October 2014 21:19, Philip Jenvey <pjenvey at underboss.org> wrote:
>> > Could someone with access update and cycle the buildbot when they get
>> > the chance?
>>
>> Updated it one or two days ago.  It is at current tip (a768fa781d1b).
>>
>>
>> Armin
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From ram at rachum.com  Sat Oct 18 11:36:05 2014
From: ram at rachum.com (Ram Rachum)
Date: Sat, 18 Oct 2014 12:36:05 +0300
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
 <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
Message-ID: <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>

Matti, are you the admin of the build slaves?

On Sat, Oct 18, 2014 at 12:34 PM, Maciej Fijalkowski <fijall at gmail.com>
wrote:

> both slaves are offline, pester the admins to bring them back (I've no
> clue who, matti maybe?)
>
> On Sat, Oct 18, 2014 at 11:30 AM, Ram Rachum <ram at rachum.com> wrote:
> > Armin: I don't understand how buildbots work too well, but on this page:
> >
> > http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32
> >
> > It seems that Philip scheduled a build 38 hours ago and it hasn't
> started.
> > We want it to be built.
> >
> > On Sat, Oct 18, 2014 at 9:19 AM, Armin Rigo <arigo at tunes.org> wrote:
> >>
> >> Hi Philip,
> >>
> >> On 16 October 2014 21:19, Philip Jenvey <pjenvey at underboss.org> wrote:
> >> > Could someone with access update and cycle the buildbot when they get
> >> > the chance?
> >>
> >> Updated it one or two days ago.  It is at current tip (a768fa781d1b).
> >>
> >>
> >> Armin
> >> _______________________________________________
> >> pypy-dev mailing list
> >> pypy-dev at python.org
> >> https://mail.python.org/mailman/listinfo/pypy-dev
> >
> >
> >
> > _______________________________________________
> > pypy-dev mailing list
> > pypy-dev at python.org
> > https://mail.python.org/mailman/listinfo/pypy-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/4566f95f/attachment.html>

From matti.picus at gmail.com  Sat Oct 18 15:11:11 2014
From: matti.picus at gmail.com (Matti Picus)
Date: Sat, 18 Oct 2014 08:11:11 -0500
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
 <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
 <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>
Message-ID: <544266EF.8070203@gmail.com>


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
Matti

From ram at rachum.com  Sat Oct 18 18:01:35 2014
From: ram at rachum.com (Ram Rachum)
Date: Sat, 18 Oct 2014 19:01:35 +0300
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <544266EF.8070203@gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
 <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
 <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>
 <544266EF.8070203@gmail.com>
Message-ID: <CANXboVYP9-jdALZxe2kBQd_n6YNMvODz8dkY_1SfwXCCJ01qoQ@mail.gmail.com>

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
> Matti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/d1c8c681/attachment.html>

From matti.picus at gmail.com  Sat Oct 18 18:49:25 2014
From: matti.picus at gmail.com (matti picus)
Date: Sat, 18 Oct 2014 19:49:25 +0300
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CANXboVYP9-jdALZxe2kBQd_n6YNMvODz8dkY_1SfwXCCJ01qoQ@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
 <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
 <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>
 <544266EF.8070203@gmail.com>
 <CANXboVYP9-jdALZxe2kBQd_n6YNMvODz8dkY_1SfwXCCJ01qoQ@mail.gmail.com>
Message-ID: <CAO8bCgjy4LY6DuogAq+VsBfvS9pxRQ=mB_oHX0EzZ529U-QiGQ@mail.gmail.com>

No, wait another couple of hours for the build to finish. You are looking
at the default build, yours is the py3.3 build that is waiting in line,
that's what the "lock" is on this page
http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/1607

Note that it will definitely not pass all tests, the best you can hope for
is that translation and upload succeed

Matti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/b170543e/attachment.html>

From ram at rachum.com  Sat Oct 18 18:52:37 2014
From: ram at rachum.com (Ram Rachum)
Date: Sat, 18 Oct 2014 19:52:37 +0300
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CAO8bCgjy4LY6DuogAq+VsBfvS9pxRQ=mB_oHX0EzZ529U-QiGQ@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
 <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
 <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>
 <544266EF.8070203@gmail.com>
 <CANXboVYP9-jdALZxe2kBQd_n6YNMvODz8dkY_1SfwXCCJ01qoQ@mail.gmail.com>
 <CAO8bCgjy4LY6DuogAq+VsBfvS9pxRQ=mB_oHX0EzZ529U-QiGQ@mail.gmail.com>
Message-ID: <CANXboVbx+Qsc9ed1zkrX96Gs2tZmrY61V9n4Yjzd55Qq6DLXiQ@mail.gmail.com>

Thanks Matti! I'll wait and hope for the best.

On Sat, Oct 18, 2014 at 7:49 PM, matti picus <matti.picus at gmail.com> wrote:

> No, wait another couple of hours for the build to finish. You are looking
> at the default build, yours is the py3.3 build that is waiting in line,
> that's what the "lock" is on this page
> http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/1607
>
> Note that it will definitely not pass all tests, the best you can hope for
> is that translation and upload succeed
>
> Matti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/69049f49/attachment.html>

From tbaldridge at gmail.com  Sat Oct 18 22:08:20 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Sat, 18 Oct 2014 14:08:20 -0600
Subject: [pypy-dev] Weird Unicode errors
Message-ID: <CAL36E+vgXR6=CtADhois3wW_RyN-k1o6mg2fg2A8RTNP-72u8Q@mail.gmail.com>

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:

    @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.

Timothy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/051f6151/attachment.html>

From tbaldridge at gmail.com  Sun Oct 19 01:11:08 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Sat, 18 Oct 2014 17:11:08 -0600
Subject: [pypy-dev] Weird Unicode errors
In-Reply-To: <CAL36E+vgXR6=CtADhois3wW_RyN-k1o6mg2fg2A8RTNP-72u8Q@mail.gmail.com>
References: <CAL36E+vgXR6=CtADhois3wW_RyN-k1o6mg2fg2A8RTNP-72u8Q@mail.gmail.com>
Message-ID: <CAL36E+sDqXp0bFOHWiQKn3gNP6LK7YrMEJmY=_vosvfAxn_hRQ@mail.gmail.com>

What's also odd, is that there is something non-deterministic about these
errors, sometimes I get the one error, but if I translate again (without
changing any code) I'll get the other.

On Sat, Oct 18, 2014 at 2:08 PM, Timothy Baldridge <tbaldridge at gmail.com>
wrote:

> 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:
>
>     @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.
>
> Timothy
>



-- 
?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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141018/d0666ad2/attachment-0001.html>

From ram at rachum.com  Sun Oct 19 12:45:05 2014
From: ram at rachum.com (Ram Rachum)
Date: Sun, 19 Oct 2014 13:45:05 +0300
Subject: [pypy-dev] Please update the buildbot
In-Reply-To: <CANXboVbx+Qsc9ed1zkrX96Gs2tZmrY61V9n4Yjzd55Qq6DLXiQ@mail.gmail.com>
References: <5A7740A1-9255-4B09-925F-BB6FA7A95F37@underboss.org>
 <CAMSv6X1LEc-aX5GhfuOoHhye9+UZ2r5iiFp0J8fFThsAjOb=Nw@mail.gmail.com>
 <CANXboVZbG4msaJYZApW9SBVL913a=Rrfr3WAGEjs0fZ+VHzHVQ@mail.gmail.com>
 <CAK5idxR_XOn+DHaLKw4WbfyWuey0=g8o9n3gD4sf_EEDfkOeeA@mail.gmail.com>
 <CANXboVauA4ib_d5+wEV+1RaXTKKQcVmX7SS2tRoT5HmeAP3VZg@mail.gmail.com>
 <544266EF.8070203@gmail.com>
 <CANXboVYP9-jdALZxe2kBQd_n6YNMvODz8dkY_1SfwXCCJ01qoQ@mail.gmail.com>
 <CAO8bCgjy4LY6DuogAq+VsBfvS9pxRQ=mB_oHX0EzZ529U-QiGQ@mail.gmail.com>
 <CANXboVbx+Qsc9ed1zkrX96Gs2tZmrY61V9n4Yjzd55Qq6DLXiQ@mail.gmail.com>
Message-ID: <CANXboVbdRsfiD0=DWQSk0vuHCrQuM94w5uQD0Ds=Ou=uJy0q6A@mail.gmail.com>

I see that the translation failed... Damn.

What I want is to test the package I'm going to release soon on the 3.3
version of Pypy to make sure there are no bugs. I'm not technical enough to
compile/install it on Linux. So I guess I'll wait for a Windows binary to
be released.


Thanks,
Ram.

On Sat, Oct 18, 2014 at 7:52 PM, Ram Rachum <ram at rachum.com> wrote:

> Thanks Matti! I'll wait and hope for the best.
>
> On Sat, Oct 18, 2014 at 7:49 PM, matti picus <matti.picus at gmail.com>
> wrote:
>
>> No, wait another couple of hours for the build to finish. You are looking
>> at the default build, yours is the py3.3 build that is waiting in line,
>> that's what the "lock" is on this page
>> http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/1607
>>
>> Note that it will definitely not pass all tests, the best you can hope
>> for is that translation and upload succeed
>>
>> Matti
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141019/e473e94a/attachment.html>

From umirra at gmail.com  Sun Oct 19 22:43:59 2014
From: umirra at gmail.com (Valentina Mukhamedzhanova)
Date: Sun, 19 Oct 2014 22:43:59 +0200
Subject: [pypy-dev] PyPy Warsaw Sprint (October 21-25th, 2014)
Message-ID: <CABFiF1uk_U-gh-n+gv4S8tFXq=X=ngvGaJfqpDLBUqrv2CAwMg@mail.gmail.com>

Hi,

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.


Valentina

From tbaldridge at gmail.com  Sun Oct 19 22:48:41 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Sun, 19 Oct 2014 14:48:41 -0600
Subject: [pypy-dev] Weird Unicode errors
In-Reply-To: <CAL36E+sDqXp0bFOHWiQKn3gNP6LK7YrMEJmY=_vosvfAxn_hRQ@mail.gmail.com>
References: <CAL36E+vgXR6=CtADhois3wW_RyN-k1o6mg2fg2A8RTNP-72u8Q@mail.gmail.com>
 <CAL36E+sDqXp0bFOHWiQKn3gNP6LK7YrMEJmY=_vosvfAxn_hRQ@mail.gmail.com>
Message-ID: <CAL36E+vnVteheD3cN967mTv_okmnPsCiRmT5bT3zAS=47tyB8g@mail.gmail.com>

BTW, to reproduce, you can go pull source from:
https://github.com/pixie-lang/pixie

Then run ./make-with-jit

The build script assumes that above the pixie directory you have pypy
checkout in a directory named "pypy".


On Sat, Oct 18, 2014 at 5:11 PM, Timothy Baldridge <tbaldridge at gmail.com>
wrote:

> What's also odd, is that there is something non-deterministic about these
> errors, sometimes I get the one error, but if I translate again (without
> changing any code) I'll get the other.
>
> On Sat, Oct 18, 2014 at 2:08 PM, Timothy Baldridge <tbaldridge at gmail.com>
> wrote:
>
>> 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:
>>
>>     @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.
>>
>> Timothy
>>
>
>
>
> --
> ?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)
>



-- 
?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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141019/0b1969dd/attachment.html>

From arigo at tunes.org  Mon Oct 20 12:37:10 2014
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 20 Oct 2014 12:37:10 +0200
Subject: [pypy-dev] PyPy Warsaw Sprint (October 21-25th, 2014)
In-Reply-To: <CABFiF1uk_U-gh-n+gv4S8tFXq=X=ngvGaJfqpDLBUqrv2CAwMg@mail.gmail.com>
References: <CABFiF1uk_U-gh-n+gv4S8tFXq=X=ngvGaJfqpDLBUqrv2CAwMg@mail.gmail.com>
Message-ID: <CAMSv6X18cPeBGtHXrUKFR4RWWgdhxyKoj2WU7Z73fpebruSs7w@mail.gmail.com>

Hi Valentina,

On 19 October 2014 22:43, Valentina Mukhamedzhanova <umirra at gmail.com> wrote:
> 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.

Welcome :-)


Armin

From pjenvey at underboss.org  Tue Oct 21 19:02:49 2014
From: pjenvey at underboss.org (Philip Jenvey)
Date: Tue, 21 Oct 2014 10:02:49 -0700
Subject: [pypy-dev] PyPy3 2.4.0 released
Message-ID: <272F8953-1155-4A05-B07E-1766D31E04AD@underboss.org>

=================================================
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:

    http://pypy.org/download.html

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
  faster.

* 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!

Cheers

The PyPy Team

From phyo.arkarlwin at gmail.com  Fri Oct 24 23:02:06 2014
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Sat, 25 Oct 2014 03:32:06 +0630
Subject: [pypy-dev] PyPy3 2.4.0 released
In-Reply-To: <272F8953-1155-4A05-B07E-1766D31E04AD@underboss.org>
References: <272F8953-1155-4A05-B07E-1766D31E04AD@underboss.org>
Message-ID: <CA+HjJrhnYzLcJQoc=2UX4hY2-HTikv2W-Ys_XA18bnc3AX88Ag@mail.gmail.com>

Congrats!
I am using Pypy 2.4 for tornado based web development , performance
improvement is the real deal there.

i am waiting to switch to python3 and its becoming near! Its when
pypy3 3.4 is ready (ie , Python3 is only starting to interesting after
3.4.x due to asyncio module) .

I have a question:
In CPython , python 2 vs python 3 is around 10-30% performance
difference. In PyPy world is there such difference? Same performance
between pypy2 and pypy3 ?


On Tue, Oct 21, 2014 at 11:32 PM, Philip Jenvey <pjenvey at underboss.org> wrote:
> =================================================
> 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:
>
>     http://pypy.org/download.html
>
> 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
>   faster.
>
> * 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!
>
> Cheers
>
> The PyPy Team
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From tbaldridge at gmail.com  Sat Oct 25 00:37:43 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Fri, 24 Oct 2014 16:37:43 -0600
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
Message-ID: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>

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:
https://github.com/pixie-lang/pixie/blob/master/pixie/vm/libs/ffi.py#L150

>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.

Timothy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141024/20fcdcf2/attachment.html>

From fijall at gmail.com  Sat Oct 25 10:10:29 2014
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 25 Oct 2014 10:10:29 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
Message-ID: <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>

I would not be surprised if static methods are simply unsupported by
the JIT (but likely for no good reason)

On Sat, Oct 25, 2014 at 12:37 AM, Timothy Baldridge
<tbaldridge at gmail.com> wrote:
> 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:
> https://github.com/pixie-lang/pixie/blob/master/pixie/vm/libs/ffi.py#L150
>
> 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.
>
> Timothy
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From arigo at tunes.org  Sat Oct 25 14:24:35 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 25 Oct 2014 14:24:35 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
Message-ID: <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>

Hi,

On 25 October 2014 10:10, Maciej Fijalkowski <fijall at gmail.com> wrote:
> I would not be surprised if static methods are simply unsupported by
> the JIT (but likely for no good reason)

That's not a crash of the JIT:

>> "/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>

What is unsupported at all is staticmethod objects in RPython.  I have
no clue why uncommenting that jit.unroll_safe makes the annotator sees
some staticmethod object...  You have to figure out what this pyobj
is.


A bient?t,

Armin.

From cfbolz at gmx.de  Sat Oct 25 14:42:13 2014
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sat, 25 Oct 2014 14:42:13 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
 <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
Message-ID: <544B9AA5.7030205@gmx.de>

On 25/10/14 14:24, Armin Rigo wrote:
> Hi,
> 
> On 25 October 2014 10:10, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> I would not be surprised if static methods are simply unsupported by
>> the JIT (but likely for no good reason)
> 
> That's not a crash of the JIT:
> 
>>> "/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>
> 
> What is unsupported at all is staticmethod objects in RPython.  I have
> no clue why uncommenting that jit.unroll_safe makes the annotator sees
> some staticmethod object...  You have to figure out what this pyobj
> is.

I don't understand what you mean by "staticmethod objects" being
unsupported. We use staticmethod a bit everywhere in PyPy, no?


Anyway, I tried to run translation of pixie to debug the error, and am
getting this problem:

https://bpaste.net/show/4eb70f41ce44

(which is unrelated)

Cheers,

Carl Friedrich

From arigo at tunes.org  Sat Oct 25 14:55:34 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 25 Oct 2014 14:55:34 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <544B9AA5.7030205@gmx.de>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
 <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
 <544B9AA5.7030205@gmx.de>
Message-ID: <CAMSv6X35sbp9TCe_f4cej93pgW+Ev1dHT0C9ggamxMPg3ksp6g@mail.gmail.com>

Hi Carl Friedrich,

On 25 October 2014 14:42, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> I don't understand what you mean by "staticmethod objects" being
> unsupported. We use staticmethod a bit everywhere in PyPy, no?

Unsupported as in "asking the bookkeeper for a desc for a staticmethod
object is not supported and will crash as reported".  For the common
use case of staticmethod objects which come out of classes, and are
read as normal functions, there is a special case in description.py.


A bient?t,

Armin.

From cfbolz at gmx.de  Sat Oct 25 15:00:07 2014
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sat, 25 Oct 2014 15:00:07 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <CAMSv6X35sbp9TCe_f4cej93pgW+Ev1dHT0C9ggamxMPg3ksp6g@mail.gmail.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
 <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
 <544B9AA5.7030205@gmx.de>
 <CAMSv6X35sbp9TCe_f4cej93pgW+Ev1dHT0C9ggamxMPg3ksp6g@mail.gmail.com>
Message-ID: <e3fb64c7-b1e2-4db7-8ef1-7a54677f4784@email.android.com>

Hi Armin, 

OK, that's a very nice statement for people that know the internals of the annotator, but for not really helpful for people like me who don't ;-). What does that mean on the language level? How do you 'ask the bookkeeper for a desc'? Maybe we can document that somewhere, or improve the error message. 

Cheers, 
Carl Friedrich 

On October 25, 2014 2:55:34 PM CEST, Armin Rigo <arigo at tunes.org> wrote:
>Hi Carl Friedrich,
>
>On 25 October 2014 14:42, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> I don't understand what you mean by "staticmethod objects" being
>> unsupported. We use staticmethod a bit everywhere in PyPy, no?
>
>Unsupported as in "asking the bookkeeper for a desc for a staticmethod
>object is not supported and will crash as reported".  For the common
>use case of staticmethod objects which come out of classes, and are
>read as normal functions, there is a special case in description.py.
>
>
>A bient?t,
>
>Armin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141025/fb8fe3a7/attachment.html>

From arigo at tunes.org  Sat Oct 25 15:06:20 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 25 Oct 2014 15:06:20 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <e3fb64c7-b1e2-4db7-8ef1-7a54677f4784@email.android.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
 <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
 <544B9AA5.7030205@gmx.de>
 <CAMSv6X35sbp9TCe_f4cej93pgW+Ev1dHT0C9ggamxMPg3ksp6g@mail.gmail.com>
 <e3fb64c7-b1e2-4db7-8ef1-7a54677f4784@email.android.com>
Message-ID: <CAMSv6X2KLfLjGBK7xrZkyFCobj+LjLv_EL+nOqi6dz9_3kMEeQ@mail.gmail.com>

Hi Carl Friedrich,

On 25 October 2014 15:00, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> OK, that's a very nice statement for people that know the internals of the
> annotator, but for not really helpful for people like me who don't ;-). What
> does that mean on the language level? How do you 'ask the bookkeeper for a
> desc'? Maybe we can document that somewhere, or improve the error message.

Sorry :-)  We have some staticmethod object that comes from somewhere
unexpected.  That's all I can guess by seeing Timothy's partial
traceback.  I only mentioned this because Maciej's two-lines message
was IMHO mistaken, to avoid that Timothy or someone else spends time
looking at the wrong place.  I would need to reproduce the crash to
know more precisely, but your experience with trying to do so
discourages me from trying :-)


A bient?t,

Armin.

From tbaldridge at gmail.com  Sat Oct 25 15:48:33 2014
From: tbaldridge at gmail.com (Timothy Baldridge)
Date: Sat, 25 Oct 2014 07:48:33 -0600
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <CAMSv6X2KLfLjGBK7xrZkyFCobj+LjLv_EL+nOqi6dz9_3kMEeQ@mail.gmail.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
 <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
 <544B9AA5.7030205@gmx.de>
 <CAMSv6X35sbp9TCe_f4cej93pgW+Ev1dHT0C9ggamxMPg3ksp6g@mail.gmail.com>
 <e3fb64c7-b1e2-4db7-8ef1-7a54677f4784@email.android.com>
 <CAMSv6X2KLfLjGBK7xrZkyFCobj+LjLv_EL+nOqi6dz9_3kMEeQ@mail.gmail.com>
Message-ID: <CAL36E+v+-T_9otD+ZpjKtgc5TU08v4nYFCnN9dTTEyFmNsRVBA@mail.gmail.com>

If you get latest, you should be able to get the PBC error on linux now. I
mostly develop on OSX so that was an error I needed to fix for the Linux
people.

Timothy

On Sat, Oct 25, 2014 at 7:06 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Carl Friedrich,
>
> On 25 October 2014 15:00, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> > OK, that's a very nice statement for people that know the internals of
> the
> > annotator, but for not really helpful for people like me who don't ;-).
> What
> > does that mean on the language level? How do you 'ask the bookkeeper for
> a
> > desc'? Maybe we can document that somewhere, or improve the error
> message.
>
> Sorry :-)  We have some staticmethod object that comes from somewhere
> unexpected.  That's all I can guess by seeing Timothy's partial
> traceback.  I only mentioned this because Maciej's two-lines message
> was IMHO mistaken, to avoid that Timothy or someone else spends time
> looking at the wrong place.  I would need to reproduce the crash to
> know more precisely, but your experience with trying to do so
> discourages me from trying :-)
>
>
> A bient?t,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>



-- 
?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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141025/f912875b/attachment-0001.html>

From arigo at tunes.org  Sat Oct 25 17:35:38 2014
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 25 Oct 2014 17:35:38 +0200
Subject: [pypy-dev] translation error on jit.unroll_safe with jit_libffi
In-Reply-To: <CAL36E+v+-T_9otD+ZpjKtgc5TU08v4nYFCnN9dTTEyFmNsRVBA@mail.gmail.com>
References: <CAL36E+tGGtA9nWETGV9pLdwTU0_FpZYUqmtzRHwBdUXh1sVA2A@mail.gmail.com>
 <CAK5idxTz4sgJRNoVdiHJU2aQw=7ypLKWG49n88w29sLDR95svQ@mail.gmail.com>
 <CAMSv6X3Asz0_FfxCSV+FPLNicm1GZSU=30jwOm+xi4jd_Q1+gg@mail.gmail.com>
 <544B9AA5.7030205@gmx.de>
 <CAMSv6X35sbp9TCe_f4cej93pgW+Ev1dHT0C9ggamxMPg3ksp6g@mail.gmail.com>
 <e3fb64c7-b1e2-4db7-8ef1-7a54677f4784@email.android.com>
 <CAMSv6X2KLfLjGBK7xrZkyFCobj+LjLv_EL+nOqi6dz9_3kMEeQ@mail.gmail.com>
 <CAL36E+v+-T_9otD+ZpjKtgc5TU08v4nYFCnN9dTTEyFmNsRVBA@mail.gmail.com>
Message-ID: <CAMSv6X1kmf2vRUMx9sV09EC=4euNQVZr+H9AeOsk4bV3pxmFYg@mail.gmail.com>

Hi Timothy,

On 25 October 2014 15:48, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> If you get latest, you should be able to get the PBC error on linux now. I
> mostly develop on OSX so that was an error I needed to fix for the Linux
> people.

Fixed in 76cd145da640 - 41343203ab73.  I'm not 100% sure to understand
the reasons, but this was definitely pushing the barriers of what is
or is not RPython.


A bient?t,

Armin.

From arigo at tunes.org  Mon Oct 27 13:43:55 2014
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 27 Oct 2014 13:43:55 +0100
Subject: [pypy-dev] Weird Unicode errors
In-Reply-To: <CAL36E+vnVteheD3cN967mTv_okmnPsCiRmT5bT3zAS=47tyB8g@mail.gmail.com>
References: <CAL36E+vgXR6=CtADhois3wW_RyN-k1o6mg2fg2A8RTNP-72u8Q@mail.gmail.com>
 <CAL36E+sDqXp0bFOHWiQKn3gNP6LK7YrMEJmY=_vosvfAxn_hRQ@mail.gmail.com>
 <CAL36E+vnVteheD3cN967mTv_okmnPsCiRmT5bT3zAS=47tyB8g@mail.gmail.com>
Message-ID: <CAMSv6X33Oz1eB4naM0c0Mv+rQCx1wB4i8mAFwnOmpaQ_1OUWGQ@mail.gmail.com>

Hi Timothy,

For future reference: the issue was moved to the PyPy issue tracker at
https://bitbucket.org/pypy/pypy/issue/1898 and resolved there.


Armin

From pjenvey at underboss.org  Tue Oct 28 19:23:45 2014
From: pjenvey at underboss.org (Philip Jenvey)
Date: Tue, 28 Oct 2014 11:23:45 -0700
Subject: [pypy-dev] PyPy3 2.4.0 released
Message-ID: <7B4D69CE-0FA0-4948-8E28-06F1B158DBFF@underboss.org>


On Oct 24, 2014, at 3:02 PM, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:

> Congrats!
> I am using Pypy 2.4 for tornado based web development , performance
> improvement is the real deal there.
> 
> i am waiting to switch to python3 and its becoming near! Its when
> pypy3 3.4 is ready (ie , Python3 is only starting to interesting after
> 3.4.x due to asyncio module) .
> 
> I have a question:
> In CPython , python 2 vs python 3 is around 10-30% performance
> difference. In PyPy world is there such difference? Same performance
> between pypy2 and pypy3 ?

Hi there,

PyPy3 performance isn?t quite as good as PyPy2?s yet. Our main focus has been on compatibility, as you said yourself, you probably won?t switch until a later version of Python 3?s supported.

The benchmark infrastructure for PyPy3 is in need of help. Pypy's own benchmark suite used by http://speed.pypy.org isn't Python 3 compatible yet, nor is the site really setup to run PyPy3 benchmark runs.

A few years ago there were plans for the creation of a shared between VMs/the PSF version of speed.pypy.org (to be http://speed.python.org), unfortunately these efforts seemed to have failed or at the very least stalled indefinitely.

However the benchmark suite intended for this new site supports Python 3. It?s similar to pypy?s own suite, albeit with a few different benchmarks and unfortunately separately maintained. Here?s output from a run of it with CPython 3.2.5 vs PyPy3 2.4.0: though this was ran on a laptop which isn?t going to produce the most stable numbers but it'll give you some idea:


### 2to3 ###
8.652382 -> 9.627286: 1.11x slower

### call_method ###
Min: 0.385220 -> 0.011149: 34.55x faster
Avg: 0.412039 -> 0.012474: 33.03x faster
Significant (t=293.52)
Stddev: 0.01644 -> 0.00279: 5.8934x smaller

### call_method_slots ###
Min: 0.394147 -> 0.011669: 33.78x faster
Avg: 0.419456 -> 0.013503: 31.06x faster
Significant (t=185.89)
Stddev: 0.02655 -> 0.00326: 8.1550x smaller

### call_method_unknown ###
Min: 0.416863 -> 0.016139: 25.83x faster
Avg: 0.444017 -> 0.019560: 22.70x faster
Significant (t=187.44)
Stddev: 0.02645 -> 0.00835: 3.1669x smaller

### call_simple ###
Min: 0.324141 -> 0.011182: 28.99x faster
Avg: 0.343808 -> 0.013248: 25.95x faster
Significant (t=235.96)
Stddev: 0.01667 -> 0.00406: 4.1072x smaller

### chameleon ###
Min: 0.061195 -> 0.010301: 5.94x faster
Avg: 0.066450 -> 0.015595: 4.26x faster
Significant (t=52.46)
Stddev: 0.00668 -> 0.00982: 1.4710x larger

### chaos ###
Min: 0.340240 -> 0.011240: 30.27x faster
Avg: 0.366752 -> 0.018671: 19.64x faster
Significant (t=60.31)
Stddev: 0.01713 -> 0.03704: 2.1620x larger

### django_v2 ###
Min: 0.692480 -> 0.029994: 23.09x faster
Avg: 0.731315 -> 0.037337: 19.59x faster
Significant (t=173.98)
Stddev: 0.02693 -> 0.00837: 3.2160x smaller

### etree_generate ###
Min: 0.599923 -> 1.087517: 1.81x slower
Avg: 0.636505 -> 1.149231: 1.81x slower
Significant (t=-77.16)
Stddev: 0.02478 -> 0.03993: 1.6114x larger

### etree_parse ###
Min: 0.296519 -> 0.931630: 3.14x slower
Avg: 0.331876 -> 1.010314: 3.04x slower
Significant (t=-78.30)
Stddev: 0.03799 -> 0.04807: 1.2652x larger

### etree_process ###
Min: 0.421074 -> 0.739647: 1.76x slower
Avg: 0.454918 -> 0.798387: 1.76x slower
Significant (t=-55.61)
Stddev: 0.03127 -> 0.03048: 1.0260x smaller

### fannkuch ###
Min: 1.744042 -> 0.179821: 9.70x faster
Avg: 1.815167 -> 0.193547: 9.38x faster
Significant (t=293.69)
Stddev: 0.03619 -> 0.01465: 2.4707x smaller

### fastpickle ###
Min: 0.671650 -> 109.014578: 162.31x slower
Avg: 0.708033 -> 115.379135: 162.96x slower
Significant (t=-299.42)
Stddev: 0.02026 -> 2.70799: 133.6909x larger

### fastunpickle ###
Min: 0.586665 -> 55.736337: 95.01x slower
Avg: 0.625024 -> 56.833369: 90.93x slower
Significant (t=-357.75)
Stddev: 0.02488 -> 1.11069: 44.6438x larger

### float ###
Min: 0.358756 -> 0.026437: 13.57x faster
Avg: 0.387649 -> 0.041561: 9.33x faster
Significant (t=106.89)
Stddev: 0.02159 -> 0.00762: 2.8351x smaller

### formatted_logging ###
Min: 0.306111 -> 0.086534: 3.54x faster
Avg: 0.331045 -> 0.116844: 2.83x faster
Significant (t=32.06)
Stddev: 0.02016 -> 0.04273: 2.1198x larger

### go ###
Min: 0.640692 -> 0.110813: 5.78x faster
Avg: 0.686035 -> 0.153473: 4.47x faster
Significant (t=81.23)
Stddev: 0.02366 -> 0.03987: 1.6853x larger

### hexiom2 ###
Min: 168.499830 -> 13.845624: 12.17x faster
Avg: 170.731699 -> 14.320609: 11.92x faster
Significant (t=68.55)
Stddev: 3.15634 -> 0.67173: 4.6988x smaller

### iterative_count ###
Min: 0.155776 -> 0.001828: 85.22x faster
Avg: 0.169719 -> 0.001959: 86.63x faster
Significant (t=66.83)
Stddev: 0.01775 -> 0.00017: 104.6217x smaller

### json_dump ###
Min: 0.563337 -> 2.088108: 3.71x slower
Avg: 0.600209 -> 2.212642: 3.69x slower
Significant (t=-92.38)
Stddev: 0.01963 -> 0.12185: 6.2066x larger

### json_dump_v2 ###
Min: 3.703154 -> 12.685391: 3.43x slower
Avg: 3.906239 -> 13.462007: 3.45x slower
Significant (t=-73.61)
Stddev: 0.16381 -> 0.90320: 5.5139x larger

### json_load ###
Min: 0.637112 -> 0.284530: 2.24x faster
Avg: 0.691114 -> 0.340403: 2.03x faster
Significant (t=48.13)
Stddev: 0.03443 -> 0.03834: 1.1134x larger

### mako ###
Min: 0.068892 -> 0.023433: 2.94x faster
Avg: 0.073817 -> 0.034535: 2.14x faster
Significant (t=45.74)
Stddev: 0.01044 -> 0.00868: 1.2032x smaller

### mako_v2 ###
Min: 0.055735 -> 0.023094: 2.41x faster
Avg: 0.060464 -> 0.034531: 1.75x faster
Significant (t=39.36)
Stddev: 0.01003 -> 0.01079: 1.0764x larger

### meteor_contest ###
Min: 0.234554 -> 0.101157: 2.32x faster
Avg: 0.253522 -> 0.112062: 2.26x faster
Significant (t=45.33)
Stddev: 0.01735 -> 0.01364: 1.2717x smaller

### nbody ###
Min: 0.332543 -> 0.024746: 13.44x faster
Avg: 0.352898 -> 0.026261: 13.44x faster
Significant (t=111.01)
Stddev: 0.02059 -> 0.00298: 6.9071x smaller

### normal_startup ###
Min: 0.974583 -> 1.578062: 1.62x slower
Avg: 1.011902 -> 1.640190: 1.62x slower
Significant (t=-144.15)
Stddev: 0.01753 -> 0.02535: 1.4458x larger

### nqueens ###
Min: 0.357568 -> 0.052418: 6.82x faster
Avg: 0.386644 -> 0.055879: 6.92x faster
Significant (t=98.78)
Stddev: 0.02223 -> 0.00816: 2.7244x smaller

### pathlib ###
Min: 0.119940 -> 0.384461: 3.21x slower
Avg: 0.130969 -> 0.504688: 3.85x slower
Significant (t=-142.33)
Stddev: 0.01389 -> 0.03912: 2.8161x larger

### pickle_dict ###
Min: 0.496007 -> 8.778371: 17.70x slower
Avg: 0.522927 -> 9.051905: 17.31x slower
Significant (t=-306.08)
Stddev: 0.01866 -> 0.19615: 10.5126x larger

### pickle_list ###
Min: 0.295601 -> 6.132281: 20.75x slower
Avg: 0.315390 -> 6.327789: 20.06x slower
Significant (t=-215.11)
Stddev: 0.01909 -> 0.19672: 10.3048x larger

### pidigits ###
Min: 0.345745 -> 0.297060: 1.16x faster
Avg: 0.362924 -> 0.316708: 1.15x faster
Significant (t=13.14)
Stddev: 0.01719 -> 0.01798: 1.0456x larger

### raytrace ###
Min: 1.527975 -> 0.046997: 32.51x faster
Avg: 1.575889 -> 0.052239: 30.17x faster
Significant (t=344.42)
Stddev: 0.02992 -> 0.00911: 3.2830x smaller

### regex_compile ###
Min: 0.462712 -> 0.076845: 6.02x faster
Avg: 0.489184 -> 0.159849: 3.06x faster
Significant (t=11.67)
Stddev: 0.01954 -> 0.19853: 10.1609x larger

### regex_effbot ###
Min: 0.061423 -> 0.034389: 1.79x faster
Avg: 0.065657 -> 0.041867: 1.57x faster
Significant (t=16.14)
Stddev: 0.00658 -> 0.00808: 1.2285x larger

### richards ###
Min: 0.201109 -> 0.004319: 46.56x faster
Avg: 0.215034 -> 0.004968: 43.28x faster
Significant (t=91.42)
Stddev: 0.01619 -> 0.00140: 11.5878x smaller

### silent_logging ###
Min: 0.080098 -> 0.007613: 10.52x faster
Avg: 0.085028 -> 0.009930: 8.56x faster
Significant (t=43.10)
Stddev: 0.00980 -> 0.00747: 1.3113x smaller

### simple_logging ###
Min: 0.296057 -> 0.081953: 3.61x faster
Avg: 0.315012 -> 0.110826: 2.84x faster
Significant (t=33.22)
Stddev: 0.01866 -> 0.03925: 2.1031x larger

### spectral_norm ###
Min: 0.365987 -> 0.016084: 22.75x faster
Avg: 0.393062 -> 0.018651: 21.07x faster
Significant (t=124.58)
Stddev: 0.02014 -> 0.00679: 2.9647x smaller

### startup_nosite ###
Min: 0.485740 -> 0.613260: 1.26x slower
Avg: 0.518384 -> 0.654354: 1.26x slower
Significant (t=-49.49)
Stddev: 0.01842 -> 0.02038: 1.1066x larger

### telco ###
Min: 0.773569 -> 0.043440: 17.81x faster
Avg: 0.800002 -> 0.049813: 16.06x faster
Significant (t=276.68)
Stddev: 0.01300 -> 0.01409: 1.0844x larger

### threaded_count ###
Min: 0.167072 -> 0.005613: 29.76x faster
Avg: 0.193020 -> 0.005944: 32.47x faster
Significant (t=88.19)
Stddev: 0.01499 -> 0.00036: 41.4676x smaller

### tornado_http ###
Min: 0.307076 -> 0.390125: 1.27x slower
Avg: 0.378676 -> 0.459946: 1.21x slower
Significant (t=-8.21)
Stddev: 0.04109 -> 0.09005: 2.1916x larger

### unpack_sequence ###
Min: 0.000052 -> 0.000057: 1.10x slower
Avg: 0.000077 -> 0.000404: 5.21x slower
Significant (t=-16.30)
Stddev: 0.00011 -> 0.00447: 41.4670x larger

### unpickle_list ###
Min: 0.455635 -> 0.963103: 2.11x slower
Avg: 0.514364 -> 1.017570: 1.98x slower
Significant (t=-79.98)
Stddev: 0.02640 -> 0.03581: 1.3564x larger


So PyPy3?s generally faster, except on startup and tornado_http, where it?s only slightly slower.

Then it?s quite a bit slower on ?mini interpreters? such as etree/json/Pickle. These modules also happen to be pure/mostly pure python versions on PyPy vs C versions used by CPython. Pickle looks particularly bad, I have a guess that it?s due to removal of an optimization in marshal that happened during py3k compatibility work, see:

https://bitbucket.org/pypy/pypy/src/a245775c1e3687662879fe57964a5ece689cd781/pypy/module/marshal/interp_marshal.py?at=py3k#cl-13

and it?s still slower than PyPy2 on many things.

Anyway, to reiterate we?ve pretty busy with compatibility work. We could use some help with benchmarking infrastructure =]

--
Philip Jenvey


From phyo.arkarlwin at gmail.com  Thu Oct 30 09:23:34 2014
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Thu, 30 Oct 2014 14:53:34 +0630
Subject: [pypy-dev] PyPy3 2.4.0 released
In-Reply-To: <7B4D69CE-0FA0-4948-8E28-06F1B158DBFF@underboss.org>
References: <7B4D69CE-0FA0-4948-8E28-06F1B158DBFF@underboss.org>
Message-ID: <CA+HjJrh+_sm_9S8uZpmNgUGXKJW+mNKXeBrgfg_vjzakOn401w@mail.gmail.com>

Thanks a lot for the benchmarks.

So we still have to wait , i guess.
Would be nice a blogpost with PyPy 2 vs PyPy3 vs CPython 2 and 3.



On Wed, Oct 29, 2014 at 12:53 AM, Philip Jenvey <pjenvey at underboss.org> wrote:
>
> On Oct 24, 2014, at 3:02 PM, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
>
>> Congrats!
>> I am using Pypy 2.4 for tornado based web development , performance
>> improvement is the real deal there.
>>
>> i am waiting to switch to python3 and its becoming near! Its when
>> pypy3 3.4 is ready (ie , Python3 is only starting to interesting after
>> 3.4.x due to asyncio module) .
>>
>> I have a question:
>> In CPython , python 2 vs python 3 is around 10-30% performance
>> difference. In PyPy world is there such difference? Same performance
>> between pypy2 and pypy3 ?
>
> Hi there,
>
> PyPy3 performance isn?t quite as good as PyPy2?s yet. Our main focus has been on compatibility, as you said yourself, you probably won?t switch until a later version of Python 3?s supported.
>
> The benchmark infrastructure for PyPy3 is in need of help. Pypy's own benchmark suite used by http://speed.pypy.org isn't Python 3 compatible yet, nor is the site really setup to run PyPy3 benchmark runs.
>
> A few years ago there were plans for the creation of a shared between VMs/the PSF version of speed.pypy.org (to be http://speed.python.org), unfortunately these efforts seemed to have failed or at the very least stalled indefinitely.
>
> However the benchmark suite intended for this new site supports Python 3. It?s similar to pypy?s own suite, albeit with a few different benchmarks and unfortunately separately maintained. Here?s output from a run of it with CPython 3.2.5 vs PyPy3 2.4.0: though this was ran on a laptop which isn?t going to produce the most stable numbers but it'll give you some idea:
>
>
> ### 2to3 ###
> 8.652382 -> 9.627286: 1.11x slower
>
> ### call_method ###
> Min: 0.385220 -> 0.011149: 34.55x faster
> Avg: 0.412039 -> 0.012474: 33.03x faster
> Significant (t=293.52)
> Stddev: 0.01644 -> 0.00279: 5.8934x smaller
>
> ### call_method_slots ###
> Min: 0.394147 -> 0.011669: 33.78x faster
> Avg: 0.419456 -> 0.013503: 31.06x faster
> Significant (t=185.89)
> Stddev: 0.02655 -> 0.00326: 8.1550x smaller
>
> ### call_method_unknown ###
> Min: 0.416863 -> 0.016139: 25.83x faster
> Avg: 0.444017 -> 0.019560: 22.70x faster
> Significant (t=187.44)
> Stddev: 0.02645 -> 0.00835: 3.1669x smaller
>
> ### call_simple ###
> Min: 0.324141 -> 0.011182: 28.99x faster
> Avg: 0.343808 -> 0.013248: 25.95x faster
> Significant (t=235.96)
> Stddev: 0.01667 -> 0.00406: 4.1072x smaller
>
> ### chameleon ###
> Min: 0.061195 -> 0.010301: 5.94x faster
> Avg: 0.066450 -> 0.015595: 4.26x faster
> Significant (t=52.46)
> Stddev: 0.00668 -> 0.00982: 1.4710x larger
>
> ### chaos ###
> Min: 0.340240 -> 0.011240: 30.27x faster
> Avg: 0.366752 -> 0.018671: 19.64x faster
> Significant (t=60.31)
> Stddev: 0.01713 -> 0.03704: 2.1620x larger
>
> ### django_v2 ###
> Min: 0.692480 -> 0.029994: 23.09x faster
> Avg: 0.731315 -> 0.037337: 19.59x faster
> Significant (t=173.98)
> Stddev: 0.02693 -> 0.00837: 3.2160x smaller
>
> ### etree_generate ###
> Min: 0.599923 -> 1.087517: 1.81x slower
> Avg: 0.636505 -> 1.149231: 1.81x slower
> Significant (t=-77.16)
> Stddev: 0.02478 -> 0.03993: 1.6114x larger
>
> ### etree_parse ###
> Min: 0.296519 -> 0.931630: 3.14x slower
> Avg: 0.331876 -> 1.010314: 3.04x slower
> Significant (t=-78.30)
> Stddev: 0.03799 -> 0.04807: 1.2652x larger
>
> ### etree_process ###
> Min: 0.421074 -> 0.739647: 1.76x slower
> Avg: 0.454918 -> 0.798387: 1.76x slower
> Significant (t=-55.61)
> Stddev: 0.03127 -> 0.03048: 1.0260x smaller
>
> ### fannkuch ###
> Min: 1.744042 -> 0.179821: 9.70x faster
> Avg: 1.815167 -> 0.193547: 9.38x faster
> Significant (t=293.69)
> Stddev: 0.03619 -> 0.01465: 2.4707x smaller
>
> ### fastpickle ###
> Min: 0.671650 -> 109.014578: 162.31x slower
> Avg: 0.708033 -> 115.379135: 162.96x slower
> Significant (t=-299.42)
> Stddev: 0.02026 -> 2.70799: 133.6909x larger
>
> ### fastunpickle ###
> Min: 0.586665 -> 55.736337: 95.01x slower
> Avg: 0.625024 -> 56.833369: 90.93x slower
> Significant (t=-357.75)
> Stddev: 0.02488 -> 1.11069: 44.6438x larger
>
> ### float ###
> Min: 0.358756 -> 0.026437: 13.57x faster
> Avg: 0.387649 -> 0.041561: 9.33x faster
> Significant (t=106.89)
> Stddev: 0.02159 -> 0.00762: 2.8351x smaller
>
> ### formatted_logging ###
> Min: 0.306111 -> 0.086534: 3.54x faster
> Avg: 0.331045 -> 0.116844: 2.83x faster
> Significant (t=32.06)
> Stddev: 0.02016 -> 0.04273: 2.1198x larger
>
> ### go ###
> Min: 0.640692 -> 0.110813: 5.78x faster
> Avg: 0.686035 -> 0.153473: 4.47x faster
> Significant (t=81.23)
> Stddev: 0.02366 -> 0.03987: 1.6853x larger
>
> ### hexiom2 ###
> Min: 168.499830 -> 13.845624: 12.17x faster
> Avg: 170.731699 -> 14.320609: 11.92x faster
> Significant (t=68.55)
> Stddev: 3.15634 -> 0.67173: 4.6988x smaller
>
> ### iterative_count ###
> Min: 0.155776 -> 0.001828: 85.22x faster
> Avg: 0.169719 -> 0.001959: 86.63x faster
> Significant (t=66.83)
> Stddev: 0.01775 -> 0.00017: 104.6217x smaller
>
> ### json_dump ###
> Min: 0.563337 -> 2.088108: 3.71x slower
> Avg: 0.600209 -> 2.212642: 3.69x slower
> Significant (t=-92.38)
> Stddev: 0.01963 -> 0.12185: 6.2066x larger
>
> ### json_dump_v2 ###
> Min: 3.703154 -> 12.685391: 3.43x slower
> Avg: 3.906239 -> 13.462007: 3.45x slower
> Significant (t=-73.61)
> Stddev: 0.16381 -> 0.90320: 5.5139x larger
>
> ### json_load ###
> Min: 0.637112 -> 0.284530: 2.24x faster
> Avg: 0.691114 -> 0.340403: 2.03x faster
> Significant (t=48.13)
> Stddev: 0.03443 -> 0.03834: 1.1134x larger
>
> ### mako ###
> Min: 0.068892 -> 0.023433: 2.94x faster
> Avg: 0.073817 -> 0.034535: 2.14x faster
> Significant (t=45.74)
> Stddev: 0.01044 -> 0.00868: 1.2032x smaller
>
> ### mako_v2 ###
> Min: 0.055735 -> 0.023094: 2.41x faster
> Avg: 0.060464 -> 0.034531: 1.75x faster
> Significant (t=39.36)
> Stddev: 0.01003 -> 0.01079: 1.0764x larger
>
> ### meteor_contest ###
> Min: 0.234554 -> 0.101157: 2.32x faster
> Avg: 0.253522 -> 0.112062: 2.26x faster
> Significant (t=45.33)
> Stddev: 0.01735 -> 0.01364: 1.2717x smaller
>
> ### nbody ###
> Min: 0.332543 -> 0.024746: 13.44x faster
> Avg: 0.352898 -> 0.026261: 13.44x faster
> Significant (t=111.01)
> Stddev: 0.02059 -> 0.00298: 6.9071x smaller
>
> ### normal_startup ###
> Min: 0.974583 -> 1.578062: 1.62x slower
> Avg: 1.011902 -> 1.640190: 1.62x slower
> Significant (t=-144.15)
> Stddev: 0.01753 -> 0.02535: 1.4458x larger
>
> ### nqueens ###
> Min: 0.357568 -> 0.052418: 6.82x faster
> Avg: 0.386644 -> 0.055879: 6.92x faster
> Significant (t=98.78)
> Stddev: 0.02223 -> 0.00816: 2.7244x smaller
>
> ### pathlib ###
> Min: 0.119940 -> 0.384461: 3.21x slower
> Avg: 0.130969 -> 0.504688: 3.85x slower
> Significant (t=-142.33)
> Stddev: 0.01389 -> 0.03912: 2.8161x larger
>
> ### pickle_dict ###
> Min: 0.496007 -> 8.778371: 17.70x slower
> Avg: 0.522927 -> 9.051905: 17.31x slower
> Significant (t=-306.08)
> Stddev: 0.01866 -> 0.19615: 10.5126x larger
>
> ### pickle_list ###
> Min: 0.295601 -> 6.132281: 20.75x slower
> Avg: 0.315390 -> 6.327789: 20.06x slower
> Significant (t=-215.11)
> Stddev: 0.01909 -> 0.19672: 10.3048x larger
>
> ### pidigits ###
> Min: 0.345745 -> 0.297060: 1.16x faster
> Avg: 0.362924 -> 0.316708: 1.15x faster
> Significant (t=13.14)
> Stddev: 0.01719 -> 0.01798: 1.0456x larger
>
> ### raytrace ###
> Min: 1.527975 -> 0.046997: 32.51x faster
> Avg: 1.575889 -> 0.052239: 30.17x faster
> Significant (t=344.42)
> Stddev: 0.02992 -> 0.00911: 3.2830x smaller
>
> ### regex_compile ###
> Min: 0.462712 -> 0.076845: 6.02x faster
> Avg: 0.489184 -> 0.159849: 3.06x faster
> Significant (t=11.67)
> Stddev: 0.01954 -> 0.19853: 10.1609x larger
>
> ### regex_effbot ###
> Min: 0.061423 -> 0.034389: 1.79x faster
> Avg: 0.065657 -> 0.041867: 1.57x faster
> Significant (t=16.14)
> Stddev: 0.00658 -> 0.00808: 1.2285x larger
>
> ### richards ###
> Min: 0.201109 -> 0.004319: 46.56x faster
> Avg: 0.215034 -> 0.004968: 43.28x faster
> Significant (t=91.42)
> Stddev: 0.01619 -> 0.00140: 11.5878x smaller
>
> ### silent_logging ###
> Min: 0.080098 -> 0.007613: 10.52x faster
> Avg: 0.085028 -> 0.009930: 8.56x faster
> Significant (t=43.10)
> Stddev: 0.00980 -> 0.00747: 1.3113x smaller
>
> ### simple_logging ###
> Min: 0.296057 -> 0.081953: 3.61x faster
> Avg: 0.315012 -> 0.110826: 2.84x faster
> Significant (t=33.22)
> Stddev: 0.01866 -> 0.03925: 2.1031x larger
>
> ### spectral_norm ###
> Min: 0.365987 -> 0.016084: 22.75x faster
> Avg: 0.393062 -> 0.018651: 21.07x faster
> Significant (t=124.58)
> Stddev: 0.02014 -> 0.00679: 2.9647x smaller
>
> ### startup_nosite ###
> Min: 0.485740 -> 0.613260: 1.26x slower
> Avg: 0.518384 -> 0.654354: 1.26x slower
> Significant (t=-49.49)
> Stddev: 0.01842 -> 0.02038: 1.1066x larger
>
> ### telco ###
> Min: 0.773569 -> 0.043440: 17.81x faster
> Avg: 0.800002 -> 0.049813: 16.06x faster
> Significant (t=276.68)
> Stddev: 0.01300 -> 0.01409: 1.0844x larger
>
> ### threaded_count ###
> Min: 0.167072 -> 0.005613: 29.76x faster
> Avg: 0.193020 -> 0.005944: 32.47x faster
> Significant (t=88.19)
> Stddev: 0.01499 -> 0.00036: 41.4676x smaller
>
> ### tornado_http ###
> Min: 0.307076 -> 0.390125: 1.27x slower
> Avg: 0.378676 -> 0.459946: 1.21x slower
> Significant (t=-8.21)
> Stddev: 0.04109 -> 0.09005: 2.1916x larger
>
> ### unpack_sequence ###
> Min: 0.000052 -> 0.000057: 1.10x slower
> Avg: 0.000077 -> 0.000404: 5.21x slower
> Significant (t=-16.30)
> Stddev: 0.00011 -> 0.00447: 41.4670x larger
>
> ### unpickle_list ###
> Min: 0.455635 -> 0.963103: 2.11x slower
> Avg: 0.514364 -> 1.017570: 1.98x slower
> Significant (t=-79.98)
> Stddev: 0.02640 -> 0.03581: 1.3564x larger
>
>
> So PyPy3?s generally faster, except on startup and tornado_http, where it?s only slightly slower.
>
> Then it?s quite a bit slower on ?mini interpreters? such as etree/json/Pickle. These modules also happen to be pure/mostly pure python versions on PyPy vs C versions used by CPython. Pickle looks particularly bad, I have a guess that it?s due to removal of an optimization in marshal that happened during py3k compatibility work, see:
>
> https://bitbucket.org/pypy/pypy/src/a245775c1e3687662879fe57964a5ece689cd781/pypy/module/marshal/interp_marshal.py?at=py3k#cl-13
>
> and it?s still slower than PyPy2 on many things.
>
> Anyway, to reiterate we?ve pretty busy with compatibility work. We could use some help with benchmarking infrastructure =]
>
> --
> Philip Jenvey
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From joliya.statelife at gmail.com  Thu Oct 30 13:52:40 2014
From: joliya.statelife at gmail.com (MISS.JOLIYA)
Date: Thu, 30 Oct 2014 12:52:40 +0000
Subject: [pypy-dev] Short Term Investment Saving Plan
Message-ID: <201410300751.s9U7ppwC024951@localhost.localdomain>

"PROSPECTING"
- - - - - - - - - - - - - -

Dear sir, state life has introduced a very unique short term investment plan with very attractive feature With the surety of Govt. Of Pakistan for Age Group 25 to 45 years. If you are interested to see this plan,
 send your E - mail address with your Basic information .
1.      Full Name.
2.      Your Date Of Birth
3.      Marital Status;
4.      Child Age
5.      Wife Age
6.      Your Income/Salary
7.      Your Contact No
8.      Location
 
Mohammad. Hanif. Kasbati.
STATE LIFE INSURANCE CROP OF PAKISTAN
SALES MANAGER, K C Z,
CELL NO. 0333-218-9282
OFFICE.    0092-21-32471496
SKYPE ID: m.hanif.kasbati
E. Mail. Id.  mohammadhanifkasbati at yahoo.com
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141030/f98de291/attachment.html>

From furashgary at gmail.com  Fri Oct 31 16:47:30 2014
From: furashgary at gmail.com (Gary Furash)
Date: Fri, 31 Oct 2014 08:47:30 -0700
Subject: [pypy-dev] Silly Question re PIP
Message-ID: <CABdLNwCc9TFxWE806HStZ_3viu1XEpFyk1g9ze8UuHJkTCr8zw@mail.gmail.com>

I didn't understand the documentation, but is it the case that you cannot
use PIP with pypy? When I run pypy get_pip.py, it fails.


-- gary furash | furashgary at gmail.com, 520-907-2470 | calendar
<https://www.google.com/calendar/embed?src=furashgary%40gmail.com&ctz=America/Phoenix&mode=Week>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141031/f602d8c0/attachment.html>

From amauryfa at gmail.com  Fri Oct 31 16:54:59 2014
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 31 Oct 2014 16:54:59 +0100
Subject: [pypy-dev] Silly Question re PIP
In-Reply-To: <CABdLNwCc9TFxWE806HStZ_3viu1XEpFyk1g9ze8UuHJkTCr8zw@mail.gmail.com>
References: <CABdLNwCc9TFxWE806HStZ_3viu1XEpFyk1g9ze8UuHJkTCr8zw@mail.gmail.com>
Message-ID: <CAGmFidZi4+PRTS9ETtmdpf7AnepPY+qxwa2stmzRTVFvN7+pcg@mail.gmail.com>

On my Linux box, "virtualenv" creates an environment which already contains
pip.

2014-10-31 16:47 GMT+01:00 Gary Furash <furashgary at gmail.com>:

> I didn't understand the documentation, but is it the case that you cannot
> use PIP with pypy? When I run pypy get_pip.py, it fails.
>
>
> -- gary furash | furashgary at gmail.com, 520-907-2470 | calendar
> <https://www.google.com/calendar/embed?src=furashgary%40gmail.com&ctz=America/Phoenix&mode=Week>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20141031/37a91b0d/attachment.html>