From florin.papa at intel.com  Mon Aug  1 04:02:27 2016
From: florin.papa at intel.com (Papa, Florin)
Date: Mon, 1 Aug 2016 08:02:27 +0000
Subject: [pypy-dev] NumPyPy vs NumPy
In-Reply-To: <CAMSv6X1oZzFCqS_C0ja3OBT3=wbjX=250HT-g-DjyZUGg_Y73Q@mail.gmail.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C04622@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607270927400.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C05AC7@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607271010450.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C07B24@IRSMSX101.ger.corp.intel.com>
 <CAMSv6X1oZzFCqS_C0ja3OBT3=wbjX=250HT-g-DjyZUGg_Y73Q@mail.gmail.com>
Message-ID: <3A375A669FBEFF45B6B60E689636EDCA09C0AA6F@IRSMSX101.ger.corp.intel.com>

Hi Armin,

>The table also shows that PyPy NumPyPy is really slower, even with vectorization enabled.
>It seems that the current focus of our work, on continuing to improve cpyext instead of
>numpypy, is a good idea.

Does this mean that the main direction is to support NumPy (through improving cpyext)
instead of maintaining NumPyPy? Is NumPy (with cpyext) fully supported in PyPy, or are there
any known compatibility issues?

Regards,
Florin

From fijall at gmail.com  Mon Aug  1 04:24:16 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 1 Aug 2016 10:24:16 +0200
Subject: [pypy-dev] NumPyPy vs NumPy
In-Reply-To: <3A375A669FBEFF45B6B60E689636EDCA09C0AA6F@IRSMSX101.ger.corp.intel.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C04622@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607270927400.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C05AC7@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607271010450.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C07B24@IRSMSX101.ger.corp.intel.com>
 <CAMSv6X1oZzFCqS_C0ja3OBT3=wbjX=250HT-g-DjyZUGg_Y73Q@mail.gmail.com>
 <3A375A669FBEFF45B6B60E689636EDCA09C0AA6F@IRSMSX101.ger.corp.intel.com>
Message-ID: <CAK5idxToOYFW-+4NLuSQbawUQzg1zLNmXZQw+2dcxHqTxsppWA@mail.gmail.com>

On Mon, Aug 1, 2016 at 10:02 AM, Papa, Florin <florin.papa at intel.com> wrote:
> Hi Armin,
>
>>The table also shows that PyPy NumPyPy is really slower, even with vectorization enabled.
>>It seems that the current focus of our work, on continuing to improve cpyext instead of
>>numpypy, is a good idea.
>
> Does this mean that the main direction is to support NumPy (through improving cpyext)
> instead of maintaining NumPyPy? Is NumPy (with cpyext) fully supported in PyPy, or are there
> any known compatibility issues?
>
> Regards,
> Florin

Hi Florin

The main progress is to merge the two - we want to support NumPy (via
cpyext) and we want things that are fast in numpypy (array access
predominantly) to be used via numpypy

From arigo at tunes.org  Mon Aug  1 05:02:25 2016
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 1 Aug 2016 11:02:25 +0200
Subject: [pypy-dev] NumPyPy vs NumPy
In-Reply-To: <CAK5idxToOYFW-+4NLuSQbawUQzg1zLNmXZQw+2dcxHqTxsppWA@mail.gmail.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C04622@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607270927400.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C05AC7@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607271010450.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C07B24@IRSMSX101.ger.corp.intel.com>
 <CAMSv6X1oZzFCqS_C0ja3OBT3=wbjX=250HT-g-DjyZUGg_Y73Q@mail.gmail.com>
 <3A375A669FBEFF45B6B60E689636EDCA09C0AA6F@IRSMSX101.ger.corp.intel.com>
 <CAK5idxToOYFW-+4NLuSQbawUQzg1zLNmXZQw+2dcxHqTxsppWA@mail.gmail.com>
Message-ID: <CAMSv6X1A4AW1dxvb-1yozUP6FBdV-L7gG_kRJUF4AOQ-OMTibA@mail.gmail.com>

Hi,

On 1 August 2016 at 10:24, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> Does this mean that the main direction is to support NumPy (through improving cpyext)
>> instead of maintaining NumPyPy? Is NumPy (with cpyext) fully supported in PyPy, or are there
>> any known compatibility issues?
>
> The main progress is to merge the two - we want to support NumPy (via
> cpyext) and we want things that are fast in numpypy (array access
> predominantly) to be used via numpypy

Yes, and your benchmarks reinforce the impression that
numpy-via-cpyext is faster in a lot of cases.  Moreover it is more
compatible with CPython's numpy, because supporting it fully is "only"
a matter of us improving the general cpyext compatibility layer.  Some
benchmarks like "extractint" show cases where numpy-via-cpyext suffers
from high levels of crossing the cpyext boundary.  As fijal says we
want to ultimately add some things from numpypy into numpy-via-cpyext,
maybe by patching or special-casing some methods like
ndarray.__getitem__ after the module is imported.

By the way, it would make a cool project for someone new to the pypy
code base (<= still trying to recruit help in making numpy, although
it turned out to be very difficult in the past).


A bient?t,

Armin.

From arigo at tunes.org  Mon Aug  1 05:17:59 2016
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 1 Aug 2016 11:17:59 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
Message-ID: <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>

Hi Peter,

On 29 July 2016 at 01:24, Wang, Peter Xihong
<peter.xihong.wang at intel.com> wrote:
> Armin created a minimum working version incorporating VTUNE to a branch at:
> https://bitbucket.org/pypy/pypy/branch/vtune
>
> This works in a sense such that statistically meaningful micro-architecture
> data could be collected.  However, for hot spot analysis, we?d like to trace
> back to the Python application source code.

Mapping raw addresses in JIT-generated assembly all the way back to
Python is a bit difficult, but that's what vmprof tries to do.  I can
imagine a solution based on vmprof.  For now, try to run pypy in the
vtune branch together with vmprof:
https://github.com/vmprof/vmprof-python .  I think the vmprof log file
contains some information that does the mapping we're looking for.

For now we're not actively developing the vtune branch any more, but
maybe we should.  I should add that my copy of vtune-amplifier-xe
started refusing to work, with "Error - no valid license - license
expired" and no hint about if and how to renew that license, so that
put me off.


A bient?t,

Armin.

From peter.xihong.wang at intel.com  Mon Aug  1 18:46:56 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Mon, 1 Aug 2016 22:46:56 +0000
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>

Hi Armin,

As far as I know (my team members tried this), vmprof does not allow us to attach to a running process? We will evaluate https://github.com/vmprof/vmprof-python if you think it's doable.

Regarding to license, you could get free version as an active Open Source contributor: https://software.intel.com/en-us/qualify-for-free-software, click on "Open Source Contributor".   Please let me know how it works for you.  Also, would you need a Windows version of VTUNE as well?

As far as feature is concerned, hot spot analysis on JITed code, mapping to source codes, along with getting other info, such as getting microarchitecture statistics, all on the same time, are also important to us.  

Best Regards,

Peter


?

-----Original Message-----
From: armin.rigo at gmail.com [mailto:armin.rigo at gmail.com] On Behalf Of Armin Rigo
Sent: Monday, August 01, 2016 2:18 AM
To: Wang, Peter Xihong <peter.xihong.wang at intel.com>
Cc: pypy-dev at python.org
Subject: Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

Hi Peter,

On 29 July 2016 at 01:24, Wang, Peter Xihong <peter.xihong.wang at intel.com> wrote:
> Armin created a minimum working version incorporating VTUNE to a branch at:
> https://bitbucket.org/pypy/pypy/branch/vtune
>
> This works in a sense such that statistically meaningful 
> micro-architecture data could be collected.  However, for hot spot 
> analysis, we?d like to trace back to the Python application source code.

Mapping raw addresses in JIT-generated assembly all the way back to Python is a bit difficult, but that's what vmprof tries to do.  I can imagine a solution based on vmprof.  For now, try to run pypy in the vtune branch together with vmprof:
https://github.com/vmprof/vmprof-python .  I think the vmprof log file contains some information that does the mapping we're looking for.

For now we're not actively developing the vtune branch any more, but maybe we should.  I should add that my copy of vtune-amplifier-xe started refusing to work, with "Error - no valid license - license expired" and no hint about if and how to renew that license, so that put me off.


A bient?t,

Armin.

From yashwardhan.singh at intel.com  Mon Aug  1 19:31:06 2016
From: yashwardhan.singh at intel.com (Singh, Yashwardhan)
Date: Mon, 1 Aug 2016 23:31:06 +0000
Subject: [pypy-dev] PGO Optimized PyPy Built
Message-ID: <0151F66FF725AC42A760DA612754C5F8198B21AA@ORSMSX104.amr.corp.intel.com>

Hi Everyone,

I was wondering if someone has tried to build pypy using PGO ( Profile Guided Optimization) and LTO (Link Time Optimization). CPython has an option of building the binary using PGO and LTO, which gives performance speedup upto 26% on some of the GUPB benchmarks, with average gain of 10% over the whole benchmark suite.
http://bugs.python.org/issue24915

Regards
Yash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160801/86c77b19/attachment.html>

From wickedgrey at gmail.com  Tue Aug  2 02:02:04 2016
From: wickedgrey at gmail.com (Eli Stevens (Gmail))
Date: Mon, 1 Aug 2016 23:02:04 -0700
Subject: [pypy-dev] Fwd:  NumPyPy vs NumPy
In-Reply-To: <CADa34LAuYKsXXdRZSiFJkGaa3=jbtphxonquuqWbt6A9MoG40Q@mail.gmail.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C04622@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607270927400.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C05AC7@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607271010450.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C07B24@IRSMSX101.ger.corp.intel.com>
 <CAMSv6X1oZzFCqS_C0ja3OBT3=wbjX=250HT-g-DjyZUGg_Y73Q@mail.gmail.com>
 <3A375A669FBEFF45B6B60E689636EDCA09C0AA6F@IRSMSX101.ger.corp.intel.com>
 <CAK5idxToOYFW-+4NLuSQbawUQzg1zLNmXZQw+2dcxHqTxsppWA@mail.gmail.com>
 <CAMSv6X1A4AW1dxvb-1yozUP6FBdV-L7gG_kRJUF4AOQ-OMTibA@mail.gmail.com>
 <CADa34LAuYKsXXdRZSiFJkGaa3=jbtphxonquuqWbt6A9MoG40Q@mail.gmail.com>
Message-ID: <CADa34LDFig=-oL5o0KUg7dB7p6_VDRKxGn2yPfasaig1dKL6ng@mail.gmail.com>

This was meant to go to the list, whoops.

---------- Forwarded message ----------
From: Eli Stevens (Gmail) <wickedgrey at gmail.com>
Date: Mon, Aug 1, 2016 at 11:01 PM
Subject: Re: [pypy-dev] NumPyPy vs NumPy
To: Armin Rigo <arigo at tunes.org>


On Mon, Aug 1, 2016 at 2:02 AM, Armin Rigo <arigo at tunes.org> wrote:
> By the way, it would make a cool project for someone new to the pypy
> code base (<= still trying to recruit help in making numpy, although
> it turned out to be very difficult in the past).

It's certainly something I'd be interested in attempting, but I feel
like I'm lacking some concrete direction. Some documentation about how
to get the proper environment (is it as simple as `~/venv/pypy/bin/pip
install numpy` using the cpython numpy?) and how new tests should be
written would be really helpful.

Eli

From alecsandru.patrascu at intel.com  Tue Aug  2 02:16:49 2016
From: alecsandru.patrascu at intel.com (Patrascu, Alecsandru)
Date: Tue, 2 Aug 2016 06:16:49 +0000
Subject: [pypy-dev] PGO Optimized PyPy Built
In-Reply-To: <0151F66FF725AC42A760DA612754C5F8198B21AA@ORSMSX104.amr.corp.intel.com>
References: <0151F66FF725AC42A760DA612754C5F8198B21AA@ORSMSX104.amr.corp.intel.com>
Message-ID: <3CF256F4F774BD48A1691D131AA043191431FF7B@IRSMSX102.ger.corp.intel.com>

Hello Yash,

I've done experiments with LTO/PGO on PyPy, but because you have a JIT enabled, they are useless. Let me detail this a bit more.

LTO and PGO works on CPython and gives the performance you mentioned, because the code is not dynamic in nature, you only have a large codebase, with a lot of C code, some used, some duplicated, etc. Therefore any way the static code can be optimized at compile/link time, will bring benefits.

On the other hand, if you enable LTO/PGO on non-JIT version of PyPy, you get impressive results, with up to 15% compared with the baseline (PyPy no JIT), but no one uses PyPy that way. Without JIT, PyPy it's slower than CPython.

If you enable the JIT and use LTO/PGO you actually get no overall performance gain, but performance degrading, depending on the workload you are using. For example, on the Grand Unified Python Benchmark (GUPB), the number of benchmarks that have a speedup and slowdown are about even, in the range +/-3%, as measured on our Haswell systems. These results are not unexpected or weird, since doing PGO/LTO on other projects, such as Node.JS or HHVM, which also feature a JIT, got to the same outcome.

Regards,
Alecsandru

From: pypy-dev [mailto:pypy-dev-bounces+alecsandru.patrascu=intel.com at python.org] On Behalf Of Singh, Yashwardhan
Sent: Tuesday, August 2, 2016 2:31 AM
To: pypy-dev at python.org
Subject: [pypy-dev] PGO Optimized PyPy Built

Hi Everyone,

I was wondering if someone has tried to build pypy using PGO ( Profile Guided Optimization) and LTO (Link Time Optimization). CPython has an option of building the binary using PGO and LTO, which gives performance speedup upto 26% on some of the GUPB benchmarks, with average gain of 10% over the whole benchmark suite.
http://bugs.python.org/issue24915

Regards
Yash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160802/6bf83747/attachment-0001.html>

From arigo at tunes.org  Tue Aug  2 04:02:33 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 2 Aug 2016 10:02:33 +0200
Subject: [pypy-dev] PGO Optimized PyPy Built
In-Reply-To: <3CF256F4F774BD48A1691D131AA043191431FF7B@IRSMSX102.ger.corp.intel.com>
References: <0151F66FF725AC42A760DA612754C5F8198B21AA@ORSMSX104.amr.corp.intel.com>
 <3CF256F4F774BD48A1691D131AA043191431FF7B@IRSMSX102.ger.corp.intel.com>
Message-ID: <CAMSv6X0eoPfXzOtW_7knqTDx+qVgHUWVs+JaJc-LbGDBzNF2jw@mail.gmail.com>

Hi,

On 2 August 2016 at 08:16, Patrascu, Alecsandru
<alecsandru.patrascu at intel.com> wrote:
> number of benchmarks that have a speedup and slowdown are about even, in the
> range +/-3%, as measured on our Haswell systems. These results are not
> unexpected or weird, since doing PGO/LTO on other projects, such as Node.JS
> or HHVM, which also feature a JIT, got to the same outcome.

PyPy played with profile-guided optimizations long ago, before it had
a fully-working JIT.  It gave some speed-ups, but I don't remember the
numbers (at that time they were certainly not as impressive as 26%).

With the JIT, these optimizations can still in theory help a bit for
parts that are never JITted (like ``long`` integer computations), for
the JIT warm-up itself, or for special code like the GC.  Alecsandru's
results are that it doesn't help at all, but maybe his benchmark suite
doesn't cover the kind of code where it would, like warm-up-intensive
code.  You'd need to try and measure on your own examples to be sure.
I think it can all be done by generating the C files and then tweaking
manually the Makefile.


A bient?t,

Armin.

From fijall at gmail.com  Tue Aug  2 04:09:41 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Aug 2016 10:09:41 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
Message-ID: <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>

On Tue, Aug 2, 2016 at 12:46 AM, Wang, Peter Xihong
<peter.xihong.wang at intel.com> wrote:
> Hi Armin,
>
> As far as I know (my team members tried this), vmprof does not allow us to attach to a running process? We will evaluate https://github.com/vmprof/vmprof-python if you think it's doable.

You would need some form of process cooperation (I think) but it does
not seem impossible. What I would do is I would run a separate thread
that accepts something (e.g. a pipe write) and then starts vmprof.
vmprof once started is global to all threads

From fijall at gmail.com  Tue Aug  2 04:13:10 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Aug 2016 10:13:10 +0200
Subject: [pypy-dev] Fwd: NumPyPy vs NumPy
In-Reply-To: <CADa34LDFig=-oL5o0KUg7dB7p6_VDRKxGn2yPfasaig1dKL6ng@mail.gmail.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C04622@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607270927400.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C05AC7@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607271010450.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C07B24@IRSMSX101.ger.corp.intel.com>
 <CAMSv6X1oZzFCqS_C0ja3OBT3=wbjX=250HT-g-DjyZUGg_Y73Q@mail.gmail.com>
 <3A375A669FBEFF45B6B60E689636EDCA09C0AA6F@IRSMSX101.ger.corp.intel.com>
 <CAK5idxToOYFW-+4NLuSQbawUQzg1zLNmXZQw+2dcxHqTxsppWA@mail.gmail.com>
 <CAMSv6X1A4AW1dxvb-1yozUP6FBdV-L7gG_kRJUF4AOQ-OMTibA@mail.gmail.com>
 <CADa34LAuYKsXXdRZSiFJkGaa3=jbtphxonquuqWbt6A9MoG40Q@mail.gmail.com>
 <CADa34LDFig=-oL5o0KUg7dB7p6_VDRKxGn2yPfasaig1dKL6ng@mail.gmail.com>
Message-ID: <CAK5idxTZoKsMujQ82=4kW0wsgs=AGQ9NNVbPy3NedR=nkaze=w@mail.gmail.com>

On Tue, Aug 2, 2016 at 8:02 AM, Eli Stevens (Gmail)
<wickedgrey at gmail.com> wrote:
> This was meant to go to the list, whoops.
>
> ---------- Forwarded message ----------
> From: Eli Stevens (Gmail) <wickedgrey at gmail.com>
> Date: Mon, Aug 1, 2016 at 11:01 PM
> Subject: Re: [pypy-dev] NumPyPy vs NumPy
> To: Armin Rigo <arigo at tunes.org>
>
>
> On Mon, Aug 1, 2016 at 2:02 AM, Armin Rigo <arigo at tunes.org> wrote:
>> By the way, it would make a cool project for someone new to the pypy
>> code base (<= still trying to recruit help in making numpy, although
>> it turned out to be very difficult in the past).
>
> It's certainly something I'd be interested in attempting, but I feel
> like I'm lacking some concrete direction. Some documentation about how
> to get the proper environment (is it as simple as `~/venv/pypy/bin/pip
> install numpy` using the cpython numpy?) and how new tests should be
> written would be really helpful.
>
> Eli

Hi Eli.

I'm not completely sure what you're asking about. Usually more
real-time communication via IRC helps us to clear up those
misunderstandings much easier than over the mail.

If you ask how to install C numpy - yes, like that should work (I
believe there is *some* documentation somewhere?), although I would
install a development version, Not sure about what "new tests" you're
talking about

Cheers,
fijal

From arigo at tunes.org  Tue Aug  2 04:17:35 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 2 Aug 2016 10:17:35 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
Message-ID: <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>

Hi,

On 2 August 2016 at 10:09, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> As far as I know (my team members tried this), vmprof does not allow us to attach to a running process? We will evaluate https://github.com/vmprof/vmprof-python if you think it's doable.
>
> You would need some form of process cooperation (I think) but it does
> not seem impossible. What I would do is I would run a separate thread
> that accepts something (e.g. a pipe write) and then starts vmprof.
> vmprof once started is global to all threads

Also, please note that I mentioned vmprof as a way to get started.
You would need some *like*  what vmprof does; for a clean solution you
don't want to enable an additional profiler on your vtune code.


A bient?t,

Armin.

From arigo at tunes.org  Tue Aug  2 08:52:57 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 2 Aug 2016 14:52:57 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
Message-ID: <CAMSv6X3WRdwjZXzkqb69gxaBGo4PWa3=oVwf2TDT3hEsazHzCw@mail.gmail.com>

Hi Peter,

On 2 August 2016 at 00:46, Wang, Peter Xihong
<peter.xihong.wang at intel.com> wrote:
> Regarding to license, you could get free version as an active Open Source contributor: https://software.intel.com/en-us/qualify-for-free-software, click on "Open Source Contributor".

"""I will not be compensated in any form for applications developed or
maintained with Intel? Software Development Products under the terms
of the non-commercial license""": this is the box I need to check.
The Intel license thus seems to not apply in pypy's case, even though
it is and will remain open source.  The exact text seems also to imply
that I will never in the future be allowed to get money for my work; I
would thus never recommend anyone checks this box, as it theoretically
preclude them from ever getting paid to continue working on their open
source project...


A bient?t,

Armin.

From peter.xihong.wang at intel.com  Wed Aug  3 20:20:11 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Thu, 4 Aug 2016 00:20:11 +0000
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAMSv6X3WRdwjZXzkqb69gxaBGo4PWa3=oVwf2TDT3hEsazHzCw@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X3WRdwjZXzkqb69gxaBGo4PWa3=oVwf2TDT3hEsazHzCw@mail.gmail.com>
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E1137E@ORSMSX105.amr.corp.intel.com>

Hi Armin,

I am working to get you a special license.  You will be contacted directly.

Thanks,

Peter


?
-----Original Message-----
From: armin.rigo at gmail.com [mailto:armin.rigo at gmail.com] On Behalf Of Armin Rigo
Sent: Tuesday, August 02, 2016 5:53 AM
To: Wang, Peter Xihong <peter.xihong.wang at intel.com>
Cc: pypy-dev at python.org
Subject: Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

Hi Peter,

On 2 August 2016 at 00:46, Wang, Peter Xihong <peter.xihong.wang at intel.com> wrote:
> Regarding to license, you could get free version as an active Open Source contributor: https://software.intel.com/en-us/qualify-for-free-software, click on "Open Source Contributor".

"""I will not be compensated in any form for applications developed or maintained with Intel? Software Development Products under the terms of the non-commercial license""": this is the box I need to check.
The Intel license thus seems to not apply in pypy's case, even though it is and will remain open source.  The exact text seems also to imply that I will never in the future be allowed to get money for my work; I would thus never recommend anyone checks this box, as it theoretically preclude them from ever getting paid to continue working on their open source project...


A bient?t,

Armin.

From peter.xihong.wang at intel.com  Wed Aug  3 21:05:13 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Thu, 4 Aug 2016 01:05:13 +0000
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
 <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E113B3@ORSMSX105.amr.corp.intel.com>

HI Armin and Maciej,

Let us know once you have something we could actually try.  One requirement is on the sampling/profiling overhead, ideally <1%, but >5% could be troublesome.  We'd like to allow people to do performance analysis on production systems.

Meanwhile, could I make this as two separate requests:
1.  Application hot spot analysis.  Today I could run cProfile with CPython and get application code profiles running OpenStack Swift, but can't do the same thing with PyPy
2.  JITed code (assembly) mapping back to the application Python code.  VTUNE integration with HHVM and node.js are completed and working today, and I'd hope to see same capability with PyPy.  

Thanks,

Peter

?

-----Original Message-----
From: armin.rigo at gmail.com [mailto:armin.rigo at gmail.com] On Behalf Of Armin Rigo
Sent: Tuesday, August 02, 2016 1:18 AM
To: Maciej Fijalkowski <fijall at gmail.com>
Cc: Wang, Peter Xihong <peter.xihong.wang at intel.com>; pypy-dev at python.org
Subject: Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

Hi,

On 2 August 2016 at 10:09, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> As far as I know (my team members tried this), vmprof does not allow us to attach to a running process? We will evaluate https://github.com/vmprof/vmprof-python if you think it's doable.
>
> You would need some form of process cooperation (I think) but it does 
> not seem impossible. What I would do is I would run a separate thread 
> that accepts something (e.g. a pipe write) and then starts vmprof.
> vmprof once started is global to all threads

Also, please note that I mentioned vmprof as a way to get started.
You would need some *like*  what vmprof does; for a clean solution you don't want to enable an additional profiler on your vtune code.


A bient?t,

Armin.

From fijall at gmail.com  Thu Aug  4 02:05:30 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 4 Aug 2016 08:05:30 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42E113B3@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
 <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E113B3@ORSMSX105.amr.corp.intel.com>
Message-ID: <CAK5idxTbZfdC+UpgbXBQ3==FaNmGh8mCnOjBodW2UGOw9x-0NA@mail.gmail.com>

Hi Peter

The first request is fulfilled by vmprof

The second one can be worked on using the same mechanisms as vmprof -
there is C API that given the assembler address will give you the
python stack. It's defined in
rpython/jit/backend/llsupport/src/codemap.c I believe

On Thu, Aug 4, 2016 at 3:05 AM, Wang, Peter Xihong
<peter.xihong.wang at intel.com> wrote:
> HI Armin and Maciej,
>
> Let us know once you have something we could actually try.  One requirement is on the sampling/profiling overhead, ideally <1%, but >5% could be troublesome.  We'd like to allow people to do performance analysis on production systems.
>
> Meanwhile, could I make this as two separate requests:
> 1.  Application hot spot analysis.  Today I could run cProfile with CPython and get application code profiles running OpenStack Swift, but can't do the same thing with PyPy
> 2.  JITed code (assembly) mapping back to the application Python code.  VTUNE integration with HHVM and node.js are completed and working today, and I'd hope to see same capability with PyPy.
>
> Thanks,
>
> Peter
>
>
>
> -----Original Message-----
> From: armin.rigo at gmail.com [mailto:armin.rigo at gmail.com] On Behalf Of Armin Rigo
> Sent: Tuesday, August 02, 2016 1:18 AM
> To: Maciej Fijalkowski <fijall at gmail.com>
> Cc: Wang, Peter Xihong <peter.xihong.wang at intel.com>; pypy-dev at python.org
> Subject: Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis
>
> Hi,
>
> On 2 August 2016 at 10:09, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> As far as I know (my team members tried this), vmprof does not allow us to attach to a running process? We will evaluate https://github.com/vmprof/vmprof-python if you think it's doable.
>>
>> You would need some form of process cooperation (I think) but it does
>> not seem impossible. What I would do is I would run a separate thread
>> that accepts something (e.g. a pipe write) and then starts vmprof.
>> vmprof once started is global to all threads
>
> Also, please note that I mentioned vmprof as a way to get started.
> You would need some *like*  what vmprof does; for a clean solution you don't want to enable an additional profiler on your vtune code.
>
>
> A bient?t,
>
> Armin.

From arigo at tunes.org  Thu Aug  4 02:37:20 2016
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 4 Aug 2016 08:37:20 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAK5idxTbZfdC+UpgbXBQ3==FaNmGh8mCnOjBodW2UGOw9x-0NA@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
 <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E113B3@ORSMSX105.amr.corp.intel.com>
 <CAK5idxTbZfdC+UpgbXBQ3==FaNmGh8mCnOjBodW2UGOw9x-0NA@mail.gmail.com>
Message-ID: <CAMSv6X0-TCMUGyw+Mtwe2SoGK3g3LjbvjrF3b0mO8dPvn59QsQ@mail.gmail.com>

Hi Peter,

On 4 August 2016 at 08:05, Maciej Fijalkowski <fijall at gmail.com> wrote:
> The second one can be worked on using the same mechanisms as vmprof -
> there is C API that given the assembler address will give you the
> python stack. It's defined in
> rpython/jit/backend/llsupport/src/codemap.c I believe

I should add that vtune's particular license towards Open Source
projects, trying to prevent any paid work from occurring on an open
source project, did change my position about it: I now consider vtune
as unfriendly to open source, as its license subtly prevents growth of
the projects using it.  I'm not usually the kind of guy that would go
on a rant about license A or B, but this one strikes me as unworkable.
This license is made by considering that commercial interests and open
source never interact.  I will thus reply to it by saying that I may
consider helping you anyway---for a fee, with a regular commercial
contract.


A bient?t,

Armin.

From fijall at gmail.com  Thu Aug  4 04:10:30 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 4 Aug 2016 10:10:30 +0200
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAMSv6X0-TCMUGyw+Mtwe2SoGK3g3LjbvjrF3b0mO8dPvn59QsQ@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
 <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E113B3@ORSMSX105.amr.corp.intel.com>
 <CAK5idxTbZfdC+UpgbXBQ3==FaNmGh8mCnOjBodW2UGOw9x-0NA@mail.gmail.com>
 <CAMSv6X0-TCMUGyw+Mtwe2SoGK3g3LjbvjrF3b0mO8dPvn59QsQ@mail.gmail.com>
Message-ID: <CAK5idxQw7pJCBSPkRrDJTYbpRcpi-aS0VqqHu60UWnJxSDomsg@mail.gmail.com>

On Thu, Aug 4, 2016 at 8:37 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Peter,
>
> On 4 August 2016 at 08:05, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> The second one can be worked on using the same mechanisms as vmprof -
>> there is C API that given the assembler address will give you the
>> python stack. It's defined in
>> rpython/jit/backend/llsupport/src/codemap.c I believe
>
> I should add that vtune's particular license towards Open Source
> projects, trying to prevent any paid work from occurring on an open
> source project, did change my position about it: I now consider vtune
> as unfriendly to open source, as its license subtly prevents growth of
> the projects using it.  I'm not usually the kind of guy that would go
> on a rant about license A or B, but this one strikes me as unworkable.
> This license is made by considering that commercial interests and open
> source never interact.  I will thus reply to it by saying that I may
> consider helping you anyway---for a fee, with a regular commercial
> contract.
>
>
> A bient?t,
>
> Armin.

I fully support armins position here. The notion that Open Source
developers can somehow feed of pure air *or* not use the advantage of
spending endless free hours to make some money strikes me as a very
strange concept.

From peter.xihong.wang at intel.com  Thu Aug  4 18:40:00 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Thu, 4 Aug 2016 22:40:00 +0000
Subject: [pypy-dev] how to extend VTUNE support from pypy for
 application hot spot analysis
In-Reply-To: <CAK5idxTbZfdC+UpgbXBQ3==FaNmGh8mCnOjBodW2UGOw9x-0NA@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42DFEC39@ORSMSX105.amr.corp.intel.com>
 <CAMSv6X0PgKRFvO9jusCZeA2GQEEBJd8R5LFoVXMKcGPK5D2-Ug@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E0C606@ORSMSX105.amr.corp.intel.com>
 <CAK5idxQrBHtEhgHJvvi4mmuYtT96N3yohewL_SYdX0tLuDHU+A@mail.gmail.com>
 <CAMSv6X1CD_7jsq3_KxBrxsB6uzqsBsM2iQuh6sAdY+EBg2mYoQ@mail.gmail.com>
 <371EBC7881C7844EAAF5556BFF21BCCC42E113B3@ORSMSX105.amr.corp.intel.com>
 <CAK5idxTbZfdC+UpgbXBQ3==FaNmGh8mCnOjBodW2UGOw9x-0NA@mail.gmail.com>
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E11906@ORSMSX105.amr.corp.intel.com>

Hi Armin and Maciej,

We are looking into "rpython/jit/backend/llsupport/src/codemap.c" for the mapping.  Really appreciate this tip.
Regarding to VTUNE license/open source, fully understood the concern, and I did escalate the issue.

Thanks,

Peter

?
-----Original Message-----
From: Maciej Fijalkowski [mailto:fijall at gmail.com] 
Sent: Wednesday, August 03, 2016 11:06 PM
To: Wang, Peter Xihong <peter.xihong.wang at intel.com>
Cc: Armin Rigo <arigo at tunes.org>; pypy-dev at python.org
Subject: Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

Hi Peter

The first request is fulfilled by vmprof

The second one can be worked on using the same mechanisms as vmprof - there is C API that given the assembler address will give you the python stack. It's defined in rpython/jit/backend/llsupport/src/codemap.c I believe

On Thu, Aug 4, 2016 at 3:05 AM, Wang, Peter Xihong <peter.xihong.wang at intel.com> wrote:
> HI Armin and Maciej,
>
> Let us know once you have something we could actually try.  One requirement is on the sampling/profiling overhead, ideally <1%, but >5% could be troublesome.  We'd like to allow people to do performance analysis on production systems.
>
> Meanwhile, could I make this as two separate requests:
> 1.  Application hot spot analysis.  Today I could run cProfile with 
> CPython and get application code profiles running OpenStack Swift, but can't do the same thing with PyPy 2.  JITed code (assembly) mapping back to the application Python code.  VTUNE integration with HHVM and node.js are completed and working today, and I'd hope to see same capability with PyPy.
>
> Thanks,
>
> Peter
>
>
>
> -----Original Message-----
> From: armin.rigo at gmail.com [mailto:armin.rigo at gmail.com] On Behalf Of 
> Armin Rigo
> Sent: Tuesday, August 02, 2016 1:18 AM
> To: Maciej Fijalkowski <fijall at gmail.com>
> Cc: Wang, Peter Xihong <peter.xihong.wang at intel.com>; 
> pypy-dev at python.org
> Subject: Re: [pypy-dev] how to extend VTUNE support from pypy for 
> application hot spot analysis
>
> Hi,
>
> On 2 August 2016 at 10:09, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> As far as I know (my team members tried this), vmprof does not allow us to attach to a running process? We will evaluate https://github.com/vmprof/vmprof-python if you think it's doable.
>>
>> You would need some form of process cooperation (I think) but it does 
>> not seem impossible. What I would do is I would run a separate thread 
>> that accepts something (e.g. a pipe write) and then starts vmprof.
>> vmprof once started is global to all threads
>
> Also, please note that I mentioned vmprof as a way to get started.
> You would need some *like*  what vmprof does; for a clean solution you don't want to enable an additional profiler on your vtune code.
>
>
> A bient?t,
>
> Armin.

From florin.papa at intel.com  Fri Aug  5 04:18:33 2016
From: florin.papa at intel.com (Papa, Florin)
Date: Fri, 5 Aug 2016 08:18:33 +0000
Subject: [pypy-dev] NumPyPy vs NumPy
In-Reply-To: <16a190ba-a51d-7726-bf25-865b555de74a@gmail.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C04622@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607270927400.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C05AC7@IRSMSX101.ger.corp.intel.com>
 <alpine.LRH.2.20.1607271010450.13656@vps.zaytsev.net>
 <3A375A669FBEFF45B6B60E689636EDCA09C07B24@IRSMSX101.ger.corp.intel.com>
 <7bd58bd6-ec80-1688-b0da-e836cfb7c31c@gmail.com>
 <3A375A669FBEFF45B6B60E689636EDCA09C0A13D@IRSMSX101.ger.corp.intel.com>
 <16a190ba-a51d-7726-bf25-865b555de74a@gmail.com>
Message-ID: <3A375A669FBEFF45B6B60E689636EDCA09C0C00B@IRSMSX101.ger.corp.intel.com>

> We usually hang out on IRC, you can find me there most evenings European time.

> The zip file is not a very iterative-freindly format for improving the benchmarks, how can 
> I contribute to your work?
> - There should be some kind of shell script that downloads and installs the packages from 
> a known source so anyone else can reproduce
> - You should add np.__config__.show() to the scripts so the output reflects the external 
> libraries used
> - Examine other suites to find how they display the basic python/computer/environment 
> variables in use when you run the bencmarks

> - how many cores are in use? How much memory?

> - You should check the result, for instance AFAICT the dsums benchmark does not run to 
> completion on numpypy, bincount is not implemented Matti

Thank you for your feedback.

I started the process of making the benchmarks open source, so that we can easily collaborate. Until then, I will make the modifications you suggested.

Regards,
Florin


From alona.sharpe at gmail.com  Sun Aug  7 07:05:31 2016
From: alona.sharpe at gmail.com (a sh)
Date: Sun, 7 Aug 2016 14:05:31 +0300
Subject: [pypy-dev] Building PyPy for Win 64
Message-ID: <CAEZCZQmW7YXFjVeOc_EUbK93TaNeRcgsSh+e6vEZV9m-Y-_zWw@mail.gmail.com>

Hi all,

I'm a Java developer, testing the possibility of embedding PyPy in my code
using JNI.
In order to do so I need to build PyPy for Win 64.

I am aware that it is not currently supported, but I figured I'd give it a
shot,
So I've tried building pypy2-v5.3.1-src on a Win 64 bit machine.
(with Python 2.7 installed).

Followed the instructions here http://doc.pypy.org/en/latest/windows.html
and even managed to create a cygffi-6.dll

However, attempting to build PyPy itself failed with segmentation fault.

So my question is: what am I missing?
Why did building cygffi-6.dll succeeded but building PyPy failed?
Is there something I can do to change that?

Please see log input attached.

Any help would be highly appreciated.
Best regards,
Alona.

P.S.
I'm not a windows person & kinda rust in C & compiling so please be patient
with me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160807/8dde8480/attachment-0001.html>
-------------- next part --------------
[translation:info] 2.7.10 (default, Jun  1 2015, 18:05:38) 
[GCC 4.9.2]
[platform:msg] Set platform with 'host' cc=None, using cc='gcc', version='Unknown'
[translation:info] Translating target as defined by targetpypystandalone
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/gcctest.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_0.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_0.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_0.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_0.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused -I/home/pypy/pypy2-v5.3.1-src/rpython/translator/c /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_1.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_1.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused -I/home/pypy/pypy2-v5.3.1-src/rpython/translator/c /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/rpython/translator/c/src/thread.o
[platform:WARNING] In file included from /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c:21:0:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadStart?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:66:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadStartEx?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:123:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadGetStackSize?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:128:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadSetStackSize?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:165:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] In file included from /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c:21:0:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadAfterFork?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:198:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadLockInit?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:210:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyOpaqueDealloc_ThreadLock?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:221:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadAcquireLockTimed?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:280:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] In file included from /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c:21:0:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadAcquireLock?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:188:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] In file included from /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c:21:0:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c: In function ?RPyThreadReleaseLock?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:299:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] In file included from /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_pthread.c:559:0,
[platform:WARNING]                  from /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c:21:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c: In function ?RPyGilAllocate?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c:67:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c: In function ?RPyGilAcquireSlowPath?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c:155:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c: In function ?RPyGilYieldThread?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c:178:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c: In function ?RPyGilRelease?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c:196:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c: In function ?RPyGilAcquire?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c:203:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c: In function ?RPyFetchFastGil?:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread_gil.c:210:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  }
[platform:WARNING]  ^
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c: At top level:
[platform:WARNING] /home/pypy/pypy2-v5.3.1-src/rpython/translator/c/src/thread.c:22:0: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
[platform:WARNING]  #endif
[platform:WARNING]  ^
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_1.o /tmp/usession-release-pypy2.7-v5.3.1-32595/rpython/translator/c/src/thread.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_1.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_2.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_2.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_2.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_2.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_3.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_3.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_3.o -Wl,--export-all-symbols -lutil -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_3.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_4.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_4.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_5.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_5.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_5.o -Wl,--export-all-symbols -lutil -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_5.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_6.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_6.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_7.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_7.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_7.o -Wl,--export-all-symbols -lutil -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_7.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_8.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_8.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_8.o -Wl,--export-all-symbols -lutil -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_8.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_9.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_9.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_9.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_9.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_10.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_10.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_11.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_11.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_11.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_11.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_12.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_12.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_12.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_12.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_13.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_13.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_13.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_13.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_14.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_14.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_14.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_14.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_15.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_15.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_15.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_15.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_16.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_16.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_16.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_16.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_17.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_17.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_18.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_18.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_18.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_18.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_19.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_19.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_19.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_19.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_20.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_20.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_20.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_20.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_21.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_21.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_21.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_21.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_22.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_22.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_23.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_23.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_23.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_23.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_24.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_24.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_24.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_24.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_25.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_25.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_25.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_25.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_26.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_26.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_26.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_26.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_27.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_27.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_28.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_28.o
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_29.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_29.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_29.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_29.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_30.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_30.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_30.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_30.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_31.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_31.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_31.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_31.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_32.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_32.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_32.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_32.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_33.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_33.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_33.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_33.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_34.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_34.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_34.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_34.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_35.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_35.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_35.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_35.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_36.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_36.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_36.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_36.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_37.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_37.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_37.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_37.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_38.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_38.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_38.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_38.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_39.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_39.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_39.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_39.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_40.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_40.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_40.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_40.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_41.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_41.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_41.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_41.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_42.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_42.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_42.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_42.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_43.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_43.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_43.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_43.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_44.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_44.o
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_44.c: In function ?main?:
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_44.c:92:1: warning: implicit declaration of function ?mremap? [-Wimplicit-function-declaration]
[platform:WARNING]  mremap(NULL, 0, 0, 0);
[platform:WARNING]  ^
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_44.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_44.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_45.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_45.o
[platform:execute] gcc /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_45.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/platcheck_45.exe
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused -fPIC -fvisibility=hidden -g -O0 -DRPY_EXTERN=RPY_EXPORTED -DRPYTHON_LL2CTYPES /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.o
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.c:1:0: warning: -fPIC ignored for target (all code is position independent)
[platform:WARNING]  /***** Start of precommondefs.h *****/
[platform:WARNING]  ^
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.c: In function ?pypy_macro_wrapper_malloc?:
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.c:82:68: warning: implicit declaration of function ?malloc? [-Wimplicit-function-declaration]
[platform:WARNING]  RPY_EXTERN char *pypy_macro_wrapper_malloc(Unsigned arg0) { return malloc(arg0); }
[platform:WARNING]                                                                     ^
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.c:82:68: warning: incompatible implicit declaration of built-in function ?malloc?
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.c:82:68: note: include ?<stdlib.h>? or provide a declaration of ?malloc?
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused -fPIC -fvisibility=hidden -g -O0 -DRPY_EXTERN=RPY_EXPORTED -DRPYTHON_LL2CTYPES /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.o
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.c:1:0: warning: -fPIC ignored for target (all code is position independent)
[platform:WARNING]  /***** Start of precommondefs.h *****/
[platform:WARNING]  ^
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.c: In function ?pypy_macro_wrapper_free?:
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.c:82:55: warning: implicit declaration of function ?free? [-Wimplicit-function-declaration]
[platform:WARNING]  RPY_EXTERN void pypy_macro_wrapper_free(char *arg0) { free(arg0); }
[platform:WARNING]                                                        ^
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.c:82:55: warning: incompatible implicit declaration of built-in function ?free?
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.c:82:55: note: include ?<stdlib.h>? or provide a declaration of ?free?
[platform:execute] gcc -c -O3 -fomit-frame-pointer -Wall -Wno-unused -fPIC -fvisibility=hidden -g -O0 -DRPY_EXTERN=RPY_EXPORTED -DRPYTHON_LL2CTYPES /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_2.c -o /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_2.o
[platform:WARNING] /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_2.c:1:0: warning: -fPIC ignored for target (all code is position independent)
[platform:WARNING]  /***** Start of precommondefs.h *****/
[platform:WARNING]  ^
[platform:execute] gcc -shared /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_0.o /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_1.o /tmp/usession-release-pypy2.7-v5.3.1-32595/module_cache/module_2.o -Wl,--export-all-symbols -lrt -o /tmp/usession-release-pypy2.7-v5.3.1-32595/shared_cache/externmod.dll

From arigo at tunes.org  Sun Aug  7 09:27:50 2016
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 7 Aug 2016 15:27:50 +0200
Subject: [pypy-dev] Building PyPy for Win 64
In-Reply-To: <CAEZCZQmW7YXFjVeOc_EUbK93TaNeRcgsSh+e6vEZV9m-Y-_zWw@mail.gmail.com>
References: <CAEZCZQmW7YXFjVeOc_EUbK93TaNeRcgsSh+e6vEZV9m-Y-_zWw@mail.gmail.com>
Message-ID: <CAMSv6X2Ko=Zfntizqiybe+-HZXHNEmPvxXb2=CRsgEY0zpb3Bw@mail.gmail.com>

Hi,

On 7 August 2016 at 13:05, a sh <alona.sharpe at gmail.com> wrote:
> In order to do so I need to build PyPy for Win 64.

In case you missed it, see this section of the windows page:

http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit-translation

In particular there is (in our opinion) no point in trying to
translate PyPy before the majority of test failures are first
addressed.


A bient?t,

Armin.

From Nirav.Trivedi at Advaiya.com  Mon Aug  8 01:57:58 2016
From: Nirav.Trivedi at Advaiya.com (Nirav Trivedi)
Date: Mon, 8 Aug 2016 05:57:58 +0000
Subject: [pypy-dev] How to do import Python library to pypy
Message-ID: <DM5PR05MB2858DB35EB71FCB55AD6F1CAEB1B0@DM5PR05MB2858.namprd05.prod.outlook.com>

Hello,

How do I import Python library to pypy. Example for 'cv2' which is support in Python but it cannot support the pypy then how do import cv2 library for pypy


- Nirav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160808/01aecb11/attachment.html>

From arigo at tunes.org  Mon Aug  8 05:23:05 2016
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 8 Aug 2016 11:23:05 +0200
Subject: [pypy-dev] How to do import Python library to pypy
In-Reply-To: <DM5PR05MB2858DB35EB71FCB55AD6F1CAEB1B0@DM5PR05MB2858.namprd05.prod.outlook.com>
References: <DM5PR05MB2858DB35EB71FCB55AD6F1CAEB1B0@DM5PR05MB2858.namprd05.prod.outlook.com>
Message-ID: <CAMSv6X0OStK=rzehDLqdfHzAm5dL_jE18q+BbyPpkn4hxND1OA@mail.gmail.com>

Hi Nirav,

On 8 August 2016 at 07:57, Nirav Trivedi <Nirav.Trivedi at advaiya.com> wrote:
> How do I import Python library to pypy. Example for ?cv2? which is support
> in Python but it cannot support the pypy then how do import cv2 library for
> pypy

See http://pypy.readthedocs.io/en/latest/faq.html#module-xyz-does-not-work-with-pypy-importerror
.


A bient?t,

Armin.

From hubo at jiedaibao.com  Mon Aug  8 10:00:27 2016
From: hubo at jiedaibao.com (hubo)
Date: Mon, 08 Aug 2016 22:00:27 +0800
Subject: [pypy-dev] Performance issues of socket.recv_into()
Message-ID: 57A89078.1090307@jiedaibao.com

I have been testing network I/O performance of Python and PyPy. I have used the small script in the attachment to test TCP bandwidth between two powerful servers, each has two 10Gb nics with multi-queue hardware support to form a bond, so the physical bandwidth between the servers are 20Gbps.

The script is a simple socket client/server with multiple connections on multiple threads. The server tries its best to receive all data, and the client tries its best to send data, after 30 sec, the client stops and calculates the data sent.

It seems that there is a huge performance difference for the server to use pypy or CPython:

(python = CPython, pypy = PyPy, 100.102.4.7 is my test server IP address, and 32 is the number of concurrent connections)
With python testio.py -s on another server:

pypy testio.py -c 100.102.4.7 32
total time = 30.05s, total send = 66601 MB, speed = 17.31 Gbps
python testio.py -c 100.102.4.7 32
total time = 30.08s, total send = 67008 MB, speed = 17.40 Gbps


With pypy testio.py -s on another server:

pypy testio.py -c 100.102.4.7 32
total time = 30.36s, total send = 5838 MB, speed = 1.50 Gbps
python testio.py -c 100.102.4.7 32
total time = 30.36s, total send = 5742 MB, speed = 1.48 Gbps

But when I change

        while s.recv_into(recv_buf, 0x200000):

to

        while s.recv(0x200000):

The performance difference disappears, and both PyPy server and CPython server have good performance (17+Gbps)

It is worth to point out that when using socket.recv_into(), PyPy server only uses 100% CPU (one core), while CPython uses much more. Maybe there are some unexpected issues about socket.recv_into, e.g. GIL not released?

P.S. it is interesting that though I thought recv_into() should be more efficient thant recv() since it reduces extra object creation / destruction, the test result shows that recv() outperforms recv_into(), even with CPython. With CPython, it seems server with recv() costs less CPU time than recv_into(), but having the same I/O performance.

2016-08-08


hubo 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160808/d08e400b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testio.py
Type: application/octet-stream
Size: 1587 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160808/d08e400b/attachment.obj>

From hubo at jiedaibao.com  Mon Aug  8 10:09:55 2016
From: hubo at jiedaibao.com (hubo)
Date: Mon, 08 Aug 2016 22:09:55 +0800
Subject: [pypy-dev] Performance issues of socket.recv_into()
In-Reply-To: <57A89078.1090307@jiedaibao.com>
References: <57A89078.1090307@jiedaibao.com>
Message-ID: <57A892B1.5010504@jiedaibao.com>

By the way, the result also reproduces on localhost(127.0.0.1), and change the ctypes.create_string_buffer to bytearray does not change the result.

2016-08-08 

hubo 



????"hubo" <hubo at jiedaibao.com>
?????2016-08-08 22:00
???[pypy-dev] Performance issues of socket.recv_into()
????"PyPy Developer Mailing List"<pypy-dev at python.org>
???

I have been testing network I/O performance of Python and PyPy. I have used the small script in the attachment to test TCP bandwidth between two powerful servers, each has two 10Gb nics with multi-queue hardware support to form a bond, so the physical bandwidth between the servers are 20Gbps.

The script is a simple socket client/server with multiple connections on multiple threads. The server tries its best to receive all data, and the client tries its best to send data, after 30 sec, the client stops and calculates the data sent.

It seems that there is a huge performance difference for the server to use pypy or CPython:

(python = CPython, pypy = PyPy, 100.102.4.7 is my test server IP address, and 32 is the number of concurrent connections)
With python testio.py -s on another server:

pypy testio.py -c 100.102.4.7 32
total time = 30.05s, total send = 66601 MB, speed = 17.31 Gbps
python testio.py -c 100.102.4.7 32
total time = 30.08s, total send = 67008 MB, speed = 17.40 Gbps


With pypy testio.py -s on another server:

pypy testio.py -c 100.102.4.7 32
total time = 30.36s, total send = 5838 MB, speed = 1.50 Gbps
python testio.py -c 100.102.4.7 32
total time = 30.36s, total send = 5742 MB, speed = 1.48 Gbps

But when I change

        while s.recv_into(recv_buf, 0x200000):

to

        while s.recv(0x200000):

The performance difference disappears, and both PyPy server and CPython server have good performance (17+Gbps)

It is worth to point out that when using socket.recv_into(), PyPy server only uses 100% CPU (one core), while CPython uses much more. Maybe there are some unexpected issues about socket.recv_into, e.g. GIL not released?

P.S. it is interesting that though I thought recv_into() should be more efficient thant recv() since it reduces extra object creation / destruction, the test result shows that recv() outperforms recv_into(), even with CPython. With CPython, it seems server with recv() costs less CPU time than recv_into(), but having the same I/O performance.

2016-08-08


hubo 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160808/0a7e0ff1/attachment-0001.html>

From arigo at tunes.org  Tue Aug  9 05:30:35 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 9 Aug 2016 11:30:35 +0200
Subject: [pypy-dev] Performance issues of socket.recv_into()
In-Reply-To: <57A892B1.5010504@jiedaibao.com>
References: <57A89078.1090307@jiedaibao.com> <57A892B1.5010504@jiedaibao.com>
Message-ID: <CAMSv6X1_Av3FZ77sb1GTSSXXV1Qvd6tO79zMRPOfr9jr3V9Jdw@mail.gmail.com>

Hi,

On 8 August 2016 at 16:09, hubo <hubo at jiedaibao.com> wrote:
> P.S. it is interesting that though I thought recv_into() should be more
> efficient thant recv() since it reduces extra object creation / destruction,
> the test result shows that recv() outperforms recv_into(), even with
> CPython. With CPython, it seems server with recv() costs less CPU time than
> recv_into(), but having the same I/O performance.

As you found out, recv_into() is not better than recv() in your use
case.  (There are other use cases where it can be useful, e.g. to
receive in the middle of a buffer where there is already some data in
the beginning of the buffer and you want all data concatenated.)

Indeed, the current PyPy implementation of recv_into() is definitely
bad.  It just does a regular recv(), and then it manually copies the
data into the buffer!  So it always done one more copy of the data
than recv().

I just fixed it in e53ea5c9c384.  Now in PyPy (like in CPython), both
recv() and recv_into() don't copy the received data at all.  The
difference between the two in this case is completely lost in the
noise---it's the difference between doing a malloc or not, which costs
nothing compared to transferring 2MB of data from the kernel to
userspace.


A bient?t,

Armin.

From hubo at jiedaibao.com  Tue Aug  9 09:08:09 2016
From: hubo at jiedaibao.com (hubo)
Date: Tue, 09 Aug 2016 21:08:09 +0800
Subject: [pypy-dev] Performance issues of socket.recv_into()
In-Reply-To: <CAMSv6X1_Av3FZ77sb1GTSSXXV1Qvd6tO79zMRPOfr9jr3V9Jdw@mail.gmail.com>
References: <57A89078.1090307@jiedaibao.com> <57A892B1.5010504@jiedaibao.com>
 <CAMSv6X1_Av3FZ77sb1GTSSXXV1Qvd6tO79zMRPOfr9jr3V9Jdw@mail.gmail.com>
Message-ID: <57A9D5B5.1020205@jiedaibao.com>

Unfortunately, "to receive in the middle of a buffer where there is already some data in 
the beginning of the buffer and you want all data concatenated", that is exactly what I really want... This test script is just a simplified version. So I am really sad to find out that recv_into() is not very efficient.

What I am really insterested in is that it seems it works exactly as two lines of Python code which first do a recv() and then copy the data to the buffer, which means maybe the copy is done with GIL locked. I think that is the source of the huge performance difference. In CPython, recv_into() executes without GIL locked, so multiple threads can use multiple CPUs which improves the performance a lot.

2016-08-09 

hubo 



????Armin Rigo <arigo at tunes.org>
?????2016-08-09 17:30
???Re: [pypy-dev] Performance issues of socket.recv_into()
????"hubo"<hubo at jiedaibao.com>
???"PyPy Developer Mailing List"<pypy-dev at python.org>

Hi, 

On 8 August 2016 at 16:09, hubo <hubo at jiedaibao.com> wrote: 
> P.S. it is interesting that though I thought recv_into() should be more 
> efficient thant recv() since it reduces extra object creation / destruction, 
> the test result shows that recv() outperforms recv_into(), even with 
> CPython. With CPython, it seems server with recv() costs less CPU time than 
> recv_into(), but having the same I/O performance. 

As you found out, recv_into() is not better than recv() in your use 
case.  (There are other use cases where it can be useful, e.g. to 
receive in the middle of a buffer where there is already some data in 
the beginning of the buffer and you want all data concatenated.) 

Indeed, the current PyPy implementation of recv_into() is definitely 
bad.  It just does a regular recv(), and then it manually copies the 
data into the buffer!  So it always done one more copy of the data 
than recv(). 

I just fixed it in e53ea5c9c384.  Now in PyPy (like in CPython), both 
recv() and recv_into() don't copy the received data at all.  The 
difference between the two in this case is completely lost in the 
noise---it's the difference between doing a malloc or not, which costs 
nothing compared to transferring 2MB of data from the kernel to 
userspace. 


A bient?t, 

Armin. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160809/b84a4d86/attachment.html>

From arigo at tunes.org  Tue Aug  9 09:10:28 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 9 Aug 2016 15:10:28 +0200
Subject: [pypy-dev] Performance issues of socket.recv_into()
In-Reply-To: <57A9D5B5.1020205@jiedaibao.com>
References: <57A89078.1090307@jiedaibao.com> <57A892B1.5010504@jiedaibao.com>
 <CAMSv6X1_Av3FZ77sb1GTSSXXV1Qvd6tO79zMRPOfr9jr3V9Jdw@mail.gmail.com>
 <57A9D5B5.1020205@jiedaibao.com>
Message-ID: <CAMSv6X23xNg0jdpYWcS1dK3g3quP5ORJGe1_Hzc4WVcYik900w@mail.gmail.com>

Hi,

On 9 August 2016 at 15:08, hubo <hubo at jiedaibao.com> wrote:
> Unfortunately, "to receive in the middle of a buffer where there is already
> some data in
> the beginning of the buffer and you want all data concatenated", that is
> exactly what I really want... This test script is just a simplified version.
> So I am really sad to find out that recv_into() is not very efficient.

As I said: I have fixed it now.  The next release of PyPy will contain
an efficient recv_into().


A bient?t,

Armin.

From hubo at jiedaibao.com  Tue Aug  9 09:14:55 2016
From: hubo at jiedaibao.com (hubo)
Date: Tue, 09 Aug 2016 21:14:55 +0800
Subject: [pypy-dev] Performance issues of socket.recv_into()
In-Reply-To: <CAMSv6X23xNg0jdpYWcS1dK3g3quP5ORJGe1_Hzc4WVcYik900w@mail.gmail.com>
References: <57A89078.1090307@jiedaibao.com> <57A892B1.5010504@jiedaibao.com>
 <CAMSv6X1_Av3FZ77sb1GTSSXXV1Qvd6tO79zMRPOfr9jr3V9Jdw@mail.gmail.com>
 <57A9D5B5.1020205@jiedaibao.com>
 <CAMSv6X23xNg0jdpYWcS1dK3g3quP5ORJGe1_Hzc4WVcYik900w@mail.gmail.com>
Message-ID: <57A9D74C.2000107@jiedaibao.com>

Thanks a lot, I'm really looking forward to it!

2016-08-09 

hubo 



????Armin Rigo <arigo at tunes.org>
?????2016-08-09 21:10
???Re: [pypy-dev] Performance issues of socket.recv_into()
????"hubo"<hubo at jiedaibao.com>
???"PyPy Developer Mailing List"<pypy-dev at python.org>

Hi, 

On 9 August 2016 at 15:08, hubo <hubo at jiedaibao.com> wrote: 
> Unfortunately, "to receive in the middle of a buffer where there is already 
> some data in 
> the beginning of the buffer and you want all data concatenated", that is 
> exactly what I really want... This test script is just a simplified version. 
> So I am really sad to find out that recv_into() is not very efficient. 

As I said: I have fixed it now.  The next release of PyPy will contain 
an efficient recv_into(). 


A bient?t, 

Armin. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160809/24b8f443/attachment-0001.html>

From vincent.legoll at gmail.com  Tue Aug  9 09:44:33 2016
From: vincent.legoll at gmail.com (Vincent Legoll)
Date: Tue, 9 Aug 2016 15:44:33 +0200
Subject: [pypy-dev] Performance issues of socket.recv_into()
In-Reply-To: <57A9D74C.2000107@jiedaibao.com>
References: <57A89078.1090307@jiedaibao.com> <57A892B1.5010504@jiedaibao.com>
 <CAMSv6X1_Av3FZ77sb1GTSSXXV1Qvd6tO79zMRPOfr9jr3V9Jdw@mail.gmail.com>
 <57A9D5B5.1020205@jiedaibao.com>
 <CAMSv6X23xNg0jdpYWcS1dK3g3quP5ORJGe1_Hzc4WVcYik900w@mail.gmail.com>
 <57A9D74C.2000107@jiedaibao.com>
Message-ID: <CAEwRq=o8qC5qWOy9xK8e4q3V95+92fLmXKN=CE9xW1wxYcWn-w@mail.gmail.com>

On Tue, Aug 9, 2016 at 3:14 PM, hubo <hubo at jiedaibao.com> wrote:
> Thanks a lot, I'm really looking forward to it!

You can try a daily build, starting from tomorrow...

-- 
Vincent Legoll

From fijall at gmail.com  Mon Aug 15 18:05:53 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 16 Aug 2016 07:05:53 +0900
Subject: [pypy-dev] jetbrains vulnerability and py3k money
Message-ID: <CAK5idxTNnwWrF38w_s=PXOhh77J8-5neHB=3NaUzFj3bLsxZ_g@mail.gmail.com>

So apparently someone just made a big donation to pypy 3k project.

Details here: http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-remote-code-execution-and-local-file-disclosure-vulnerability-analysis/

Cheers,
fijal

From alex.gaynor at gmail.com  Mon Aug 15 18:10:42 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 15 Aug 2016 18:10:42 -0400
Subject: [pypy-dev] jetbrains vulnerability and py3k money
In-Reply-To: <CAK5idxTNnwWrF38w_s=PXOhh77J8-5neHB=3NaUzFj3bLsxZ_g@mail.gmail.com>
References: <CAK5idxTNnwWrF38w_s=PXOhh77J8-5neHB=3NaUzFj3bLsxZ_g@mail.gmail.com>
Message-ID: <CAFRnB2WteuEXhcjQfoutzpnB1AByTKUAPLSQcJa5_k6hj_m_+w@mail.gmail.com>

Cool!

On Mon, Aug 15, 2016 at 6:05 PM, Maciej Fijalkowski <fijall at gmail.com>
wrote:

> So apparently someone just made a big donation to pypy 3k project.
>
> Details here: http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-
> remote-code-execution-and-local-file-disclosure-vulnerability-analysis/
>
> Cheers,
> fijal
> _______________________________________________
> 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: D1B3 ADC0 E023 8CA6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160815/8115bde5/attachment.html>

From phyo.arkarlwin at gmail.com  Mon Aug 15 18:50:22 2016
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Mon, 15 Aug 2016 22:50:22 +0000
Subject: [pypy-dev] jetbrains vulnerability and py3k money
In-Reply-To: <CAFRnB2WteuEXhcjQfoutzpnB1AByTKUAPLSQcJa5_k6hj_m_+w@mail.gmail.com>
References: <CAK5idxTNnwWrF38w_s=PXOhh77J8-5neHB=3NaUzFj3bLsxZ_g@mail.gmail.com>
 <CAFRnB2WteuEXhcjQfoutzpnB1AByTKUAPLSQcJa5_k6hj_m_+w@mail.gmail.com>
Message-ID: <CA+HjJrhEpmttM-wH4njCJEzfrQ=EFo8Th9ke8khBUkdTTaE9zg@mail.gmail.com>

WOW , Wow!!
Pypy3k coming!! Time to swtich to Python3 totally.
Please Quick push forward 3.5 guys!!


On Tue, Aug 16, 2016 at 4:41 AM Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Cool!
>
> On Mon, Aug 15, 2016 at 6:05 PM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
>
>> So apparently someone just made a big donation to pypy 3k project.
>>
>> Details here:
>> http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-remote-code-execution-and-local-file-disclosure-vulnerability-analysis/
>>
>> Cheers,
>> fijal
>> _______________________________________________
>> 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: D1B3 ADC0 E023 8CA6
>
> _______________________________________________
> 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/20160815/6eefab7a/attachment.html>

From phyo.arkarlwin at gmail.com  Tue Aug 16 14:06:40 2016
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Tue, 16 Aug 2016 18:06:40 +0000
Subject: [pypy-dev] pypy segfault while playing around with odoo.
Message-ID: <CA+HjJrjxLQT0g7hOBmzVhMQf5DETzY63EeR9omoS60=pxbCc7A@mail.gmail.com>

Hello Pypy team.

i am using latest pypy , to try odoo with pypy , to see if it is compatible
enough now .
it fails while compliling gevent and pyscopg but i switched them to
gevent>=1.1
psycopg2cffi>=2.5.4 . that get it going to the point that odoo able to run.

But i got to a stop when creating new db and it crashed with segfault.

How can i debug segfaults in pypy.

Regards,

Phyo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160816/4f1e8ac5/attachment.html>

From sergey.forum at gmail.com  Wed Aug 17 02:50:39 2016
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 17 Aug 2016 09:50:39 +0300
Subject: [pypy-dev]  Django DateField default value and migrations fail
Message-ID: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>

Hi All,

there was a problem

https://bitbucket.org/pypy/pypy/issues/2062/inconsistency-in-__repr__-for-date-time

which caused Django not to make migrations
https://code.djangoproject.com/ticket/24779

and the problem was fixed

https://bitbucket.org/pypy/pypy/pull-requests/325/fixed-2062-treated-date-datetime-time/diff

but it works for correct migrations fine for default values for Django with
DateTimeField

say
class SomeClass(models.Model):
    date_add = models.DateTimeField(verbose_name=_('date created'),
default=timezone.now)

but code for DataField with default values

from datetime import date

class AnotherClass(models.Model):

    start_date = models.DateField(
        verbose_name=u'start date',
        default=date.today,
        )

    end_date = models.DateField(
        verbose_name=u'end date',
       default=date.today,
        )

still causes error of the kind:

topics/migrations/#migration-serializing" % (value, get_docs_version())
ValueError: Cannot serialize: <bound method type.today of <class
'datetime.date'

so somehow something else should be fixed in the same way it was done - but
I cannot figure out where to look at.
( and it works ok with standard Python and Django )

Any tips?

Regards
Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160817/d0ea42de/attachment.html>

From william.leslie.ttg at gmail.com  Wed Aug 17 03:23:10 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Wed, 17 Aug 2016 17:23:10 +1000
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
Message-ID: <CAHgd1hF4XXeY08uaygxqwwFb3BeHDLrJgNxbChPU=fvYna5o6A@mail.gmail.com>

Darn reply-to not being set.  Sorry Sergey.

On 17 August 2016 at 17:21, William ML Leslie
<william.leslie.ttg at gmail.com> wrote:
> On 17 August 2016 at 16:50, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
>>
>> still causes error of the kind:
>>
>> topics/migrations/#migration-serializing" % (value, get_docs_version())
>> ValueError: Cannot serialize: <bound method type.today of <class
>> 'datetime.date'
>
> Do you get a full traceback?  That would be much more useful for
> tracking down the problem.
>
> --
> William Leslie
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> prior contractual agreement.



-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

From sergey.forum at gmail.com  Wed Aug 17 03:27:25 2016
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 17 Aug 2016 10:27:25 +0300
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
Message-ID: <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>

Hi William,

here is my traceback in console

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/pypy2.7/dist-packages/django/core/management/__init__.py",
line 353, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/pypy2.7/dist-packages/django/core/management/__init__.py",
line 345, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/pypy2.7/dist-packages/django/core/management/base.py",
line 348, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/pypy2.7/dist-packages/django/core/management/base.py",
line 399, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/pypy2.7/dist-packages/django/core/
management/commands/makemigrations.py", line 150, in handle
    self.write_migration_files(changes)
  File "/usr/local/lib/pypy2.7/dist-packages/django/core/
management/commands/makemigrations.py", line 178, in write_migration_files
    migration_string = writer.as_string()
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 167, in as_string
    operation_string, operation_imports = OperationWriter(operation).
serialize()
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 124, in serialize
    _write(arg_name, arg_value)
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 76, in _write
    arg_string, arg_imports = MigrationWriter.serialize(item)
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 357, in serialize
    item_string, item_imports = cls.serialize(item)
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 433, in serialize
    return cls.serialize_deconstructed(path, args, kwargs)
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 318, in serialize_deconstructed
    arg_string, arg_imports = cls.serialize(arg)
  File "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
line 540, in serialize
    "topics/migrations/#migration-serializing" % (value, get_docs_version())
ValueError: Cannot serialize: <bound method type.today of <class
'datetime.date'>>



Regards
Sergey

On Wed, Aug 17, 2016 at 10:21 AM, William ML Leslie <
william.leslie.ttg at gmail.com> wrote:

> On 17 August 2016 at 16:50, Sergey Kurdakov <sergey.forum at gmail.com>
> wrote:
> >
> > still causes error of the kind:
> >
> > topics/migrations/#migration-serializing" % (value, get_docs_version())
> > ValueError: Cannot serialize: <bound method type.today of <class
> > 'datetime.date'
>
> Do you get a full traceback?  That would be much more useful for
> tracking down the problem.
>
> --
> William Leslie
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> prior contractual agreement.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160817/34d638ef/attachment-0001.html>

From sergey.forum at gmail.com  Wed Aug 17 04:02:08 2016
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 17 Aug 2016 11:02:08 +0300
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
Message-ID: <CAFVQEu3VgB3qA7LRBmY8xeUMtng-tsOitN-cMCh00LoAdqO-AA@mail.gmail.com>

Hi William.

I have created a test project ( just a new Django Project in PythonStudio
so it is tested in Windows too, but this code will work on linux too )

http://ananas.ws/media/DjangoTest.zip

unzip
go to DjangoTest main directory and try to make migrations:

DjangoTest>pypy manage.py makemigrations

you'll get an error at the only  model  in the app
DjangoTest\app\models.py


from datetime import date


class TestClass(models.Model):

    start_date = models.DateField(
        verbose_name=u'start date',
        default=date.today,
        )

Best regards
Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160817/47605df8/attachment.html>

From william.leslie.ttg at gmail.com  Wed Aug 17 04:04:59 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Wed, 17 Aug 2016 18:04:59 +1000
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
Message-ID: <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>

I took a look at the Django source.

There's code for serialising methods in Django that checks `if
isinstance(value, (types.FunctionType, types.BuiltinFunctionType))`
which succeeds on cpython because datetime.date.today is a
BuiltinFunctionType, wheras it's a types.MethodType on pypy.  Maybe
that check could be expanded to include MethodType.

Here's the code at master:

https://github.com/django/django/blob/3b383085fb89a48e756383e7cd5d3bd867353ba1/django/db/migrations/serializer.py#L379


On 17 August 2016 at 17:27, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
> Hi William,
>
> here is my traceback in console
>
> Traceback (most recent call last):
>   File "manage.py", line 10, in <module>
>     execute_from_command_line(sys.argv)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/core/management/__init__.py",
> line 353, in execute_from_command_line
>     utility.execute()
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/core/management/__init__.py",
> line 345, in execute
>     self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/core/management/base.py", line
> 348, in run_from_argv
>     self.execute(*args, **cmd_options)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/core/management/base.py", line
> 399, in execute
>     output = self.handle(*args, **options)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/core/management/commands/makemigrations.py",
> line 150, in handle
>     self.write_migration_files(changes)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/core/management/commands/makemigrations.py",
> line 178, in write_migration_files
>     migration_string = writer.as_string()
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 167, in as_string
>     operation_string, operation_imports =
> OperationWriter(operation).serialize()
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 124, in serialize
>     _write(arg_name, arg_value)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 76, in _write
>     arg_string, arg_imports = MigrationWriter.serialize(item)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 357, in serialize
>     item_string, item_imports = cls.serialize(item)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 433, in serialize
>     return cls.serialize_deconstructed(path, args, kwargs)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 318, in serialize_deconstructed
>     arg_string, arg_imports = cls.serialize(arg)
>   File
> "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py", line
> 540, in serialize
>     "topics/migrations/#migration-serializing" % (value, get_docs_version())
> ValueError: Cannot serialize: <bound method type.today of <class
> 'datetime.date'>>
>
>
>
> Regards
> Sergey
>
>
> On Wed, Aug 17, 2016 at 10:21 AM, William ML Leslie
> <william.leslie.ttg at gmail.com> wrote:
>>
>> On 17 August 2016 at 16:50, Sergey Kurdakov <sergey.forum at gmail.com>
>> wrote:
>> >
>> > still causes error of the kind:
>> >
>> > topics/migrations/#migration-serializing" % (value, get_docs_version())
>> > ValueError: Cannot serialize: <bound method type.today of <class
>> > 'datetime.date'
>>
>> Do you get a full traceback?  That would be much more useful for
>> tracking down the problem.
>>
>> --
>> William Leslie
>>
>> Notice:
>> Likely much of this email is, by the nature of copyright, covered
>> under copyright law.  You absolutely MAY reproduce any part of it in
>> accordance with the copyright law of the nation you are reading this
>> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
>> prior contractual agreement.
>
>



-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

From sergey.forum at gmail.com  Wed Aug 17 04:20:04 2016
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 17 Aug 2016 11:20:04 +0300
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
 <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
Message-ID: <CAFVQEu3U8Gq_EDQHu4FO12MnxYBhNNZ0w0m8+qDTexF3NToxKQ@mail.gmail.com>

Hi William,

thanks,

I solved then my problem by following code

def today():
    """
    Returns an aware or naive datetime.datetime, depending on
settings.USE_TZ.
    """
    return date.today()

class TestClass(models.Model):

    start_date = models.DateField(
        verbose_name=u'start date',
        default=today,
        )

so I just wrap required function call into function.
But this is a temporary solution. Would be great if there could be a
general one.

Regards
Sergey

On Wed, Aug 17, 2016 at 11:04 AM, William ML Leslie <
william.leslie.ttg at gmail.com> wrote:

> I took a look at the Django source.
>
> There's code for serialising methods in Django that checks `if
> isinstance(value, (types.FunctionType, types.BuiltinFunctionType))`
> which succeeds on cpython because datetime.date.today is a
> BuiltinFunctionType, wheras it's a types.MethodType on pypy.  Maybe
> that check could be expanded to include MethodType.
>
> Here's the code at master:
>
> https://github.com/django/django/blob/3b383085fb89a48e756383e7cd5d3b
> d867353ba1/django/db/migrations/serializer.py#L379
>
>
> On 17 August 2016 at 17:27, Sergey Kurdakov <sergey.forum at gmail.com>
> wrote:
> > Hi William,
> >
> > here is my traceback in console
> >
> > Traceback (most recent call last):
> >   File "manage.py", line 10, in <module>
> >     execute_from_command_line(sys.argv)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/core/
> management/__init__.py",
> > line 353, in execute_from_command_line
> >     utility.execute()
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/core/
> management/__init__.py",
> > line 345, in execute
> >     self.fetch_command(subcommand).run_from_argv(self.argv)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/core/management/base.py",
> line
> > 348, in run_from_argv
> >     self.execute(*args, **cmd_options)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/core/management/base.py",
> line
> > 399, in execute
> >     output = self.handle(*args, **options)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/core/management/commands/
> makemigrations.py",
> > line 150, in handle
> >     self.write_migration_files(changes)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/core/management/commands/
> makemigrations.py",
> > line 178, in write_migration_files
> >     migration_string = writer.as_string()
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 167, in as_string
> >     operation_string, operation_imports =
> > OperationWriter(operation).serialize()
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 124, in serialize
> >     _write(arg_name, arg_value)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 76, in _write
> >     arg_string, arg_imports = MigrationWriter.serialize(item)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 357, in serialize
> >     item_string, item_imports = cls.serialize(item)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 433, in serialize
> >     return cls.serialize_deconstructed(path, args, kwargs)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 318, in serialize_deconstructed
> >     arg_string, arg_imports = cls.serialize(arg)
> >   File
> > "/usr/local/lib/pypy2.7/dist-packages/django/db/migrations/writer.py",
> line
> > 540, in serialize
> >     "topics/migrations/#migration-serializing" % (value,
> get_docs_version())
> > ValueError: Cannot serialize: <bound method type.today of <class
> > 'datetime.date'>>
> >
> >
> >
> > Regards
> > Sergey
> >
> >
> > On Wed, Aug 17, 2016 at 10:21 AM, William ML Leslie
> > <william.leslie.ttg at gmail.com> wrote:
> >>
> >> On 17 August 2016 at 16:50, Sergey Kurdakov <sergey.forum at gmail.com>
> >> wrote:
> >> >
> >> > still causes error of the kind:
> >> >
> >> > topics/migrations/#migration-serializing" % (value,
> get_docs_version())
> >> > ValueError: Cannot serialize: <bound method type.today of <class
> >> > 'datetime.date'
> >>
> >> Do you get a full traceback?  That would be much more useful for
> >> tracking down the problem.
> >>
> >> --
> >> William Leslie
> >>
> >> Notice:
> >> Likely much of this email is, by the nature of copyright, covered
> >> under copyright law.  You absolutely MAY reproduce any part of it in
> >> accordance with the copyright law of the nation you are reading this
> >> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> >> prior contractual agreement.
> >
> >
>
>
>
> --
> William Leslie
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered
> under copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
> prior contractual agreement.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160817/a6482f59/attachment-0001.html>

From yury at shurup.com  Wed Aug 17 05:53:12 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Wed, 17 Aug 2016 11:53:12 +0200 (CEST)
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAFVQEu3U8Gq_EDQHu4FO12MnxYBhNNZ0w0m8+qDTexF3NToxKQ@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
 <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
 <CAFVQEu3U8Gq_EDQHu4FO12MnxYBhNNZ0w0m8+qDTexF3NToxKQ@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.1608171150510.32023@vps.zaytsev.net>

On Wed, 17 Aug 2016, Sergey Kurdakov wrote:

> class TestClass(models.Model):
> 
> ??? start_date = models.DateField(
> ??????? verbose_name=u'start date',
> ??????? default=today,
> ??????? )
> 
> so I just wrap required function call into function.

You can, of course, use a lambda, i.e. `default=lambda: date.today()` 
which is to the same effect, but a bit shorter.

> But this is a temporary solution. Would be great if there could be a 
> general one.

So does it work if you modify Django as William suggested? If yes, it 
sounds like this is better fixed in Django...

-- 
Sincerely yours,
Yury V. Zaytsev

From sergey.forum at gmail.com  Wed Aug 17 06:15:39 2016
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 17 Aug 2016 13:15:39 +0300
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <alpine.LRH.2.20.1608171150510.32023@vps.zaytsev.net>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
 <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
 <CAFVQEu3U8Gq_EDQHu4FO12MnxYBhNNZ0w0m8+qDTexF3NToxKQ@mail.gmail.com>
 <alpine.LRH.2.20.1608171150510.32023@vps.zaytsev.net>
Message-ID: <CAFVQEu3qW5jBzeYRRJiHQWi8Kfvgv5bd1_evQ9osh2Y+e1v95g@mail.gmail.com>

Hi Yury,

thanks for lambda tip,

ok I will submit a ticket to Django, will see how it goes.

Regards
Sergey

On Wed, Aug 17, 2016 at 12:53 PM, Yury V. Zaytsev <yury at shurup.com> wrote:

> On Wed, 17 Aug 2016, Sergey Kurdakov wrote:
>
> class TestClass(models.Model):
>>
>>     start_date = models.DateField(
>>         verbose_name=u'start date',
>>         default=today,
>>         )
>>
>> so I just wrap required function call into function.
>>
>
> You can, of course, use a lambda, i.e. `default=lambda: date.today()`
> which is to the same effect, but a bit shorter.
>
> But this is a temporary solution. Would be great if there could be a
>> general one.
>>
>
> So does it work if you modify Django as William suggested? If yes, it
> sounds like this is better fixed in Django...
>
> --
> Sincerely yours,
> Yury V. Zaytsev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160817/e8aab75d/attachment.html>

From william.leslie.ttg at gmail.com  Wed Aug 17 08:10:24 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Wed, 17 Aug 2016 22:10:24 +1000
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <alpine.LRH.2.20.1608171150510.32023@vps.zaytsev.net>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
 <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
 <CAFVQEu3U8Gq_EDQHu4FO12MnxYBhNNZ0w0m8+qDTexF3NToxKQ@mail.gmail.com>
 <alpine.LRH.2.20.1608171150510.32023@vps.zaytsev.net>
Message-ID: <CAHgd1hEBx5FnU+vz4_J55NwA8KHMcKq4Zj2+J1B_VAZb99i8=A@mail.gmail.com>

On 17 August 2016 at 19:53, Yury V. Zaytsev <yury at shurup.com> wrote:
> On Wed, 17 Aug 2016, Sergey Kurdakov wrote:
>
>> class TestClass(models.Model):
>>
>>     start_date = models.DateField(
>>         verbose_name=u'start date',
>>         default=today,
>>         )
>>
>> so I just wrap required function call into function.
>
>
> You can, of course, use a lambda, i.e. `default=lambda: date.today()` which
> is to the same effect, but a bit shorter.

It doesn't work with a lambda; the serialiser writes code that looks
up the function by name.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

From arigo at tunes.org  Thu Aug 18 02:54:34 2016
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 18 Aug 2016 08:54:34 +0200
Subject: [pypy-dev] pypy segfault while playing around with odoo.
In-Reply-To: <CA+HjJrjxLQT0g7hOBmzVhMQf5DETzY63EeR9omoS60=pxbCc7A@mail.gmail.com>
References: <CA+HjJrjxLQT0g7hOBmzVhMQf5DETzY63EeR9omoS60=pxbCc7A@mail.gmail.com>
Message-ID: <CAMSv6X0cEjeEvfJBTuMQpHkgZU_z2dR_Uykpu+UfGT51CXK2ig@mail.gmail.com>

Hi Phyo,

On 16 August 2016 at 20:06, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> But i got to a stop when creating new db and it crashed with segfault.

Probably the same issue as:
https://bitbucket.org/pypy/pypy/issues/2270/odoo-80-on-pypy-501-cause-segmentation

> How can i debug segfaults in pypy.

http://pypy.readthedocs.io/en/latest/faq.html#how-should-i-report-a-bug


Armin

From yury at shurup.com  Thu Aug 18 03:12:12 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Thu, 18 Aug 2016 09:12:12 +0200 (CEST)
Subject: [pypy-dev] [Cython] Fwd: Re: [Speed] New benchmark suite for Python
 (fwd)
Message-ID: <alpine.LRH.2.20.1608180910390.32023@vps.zaytsev.net>

Hi,

Probably most of you have seen that already, but maybe some have not? Any 
interest in getting, e.g. PyPy releases in?

-- 
Sincerely yours,
Yury V. Zaytsev

-------- Forwarded Message --------
Subject: Re: [Speed] New benchmark suite for Python
Date: Wed, 17 Aug 2016 23:47:29 -0500
From: Zachary Ware <zachary.ware+pydev(AT)gmail.com>
To: speed(AT)python.org

On Wed, Aug 17, 2016 at 7:37 PM, Victor Stinner wrote:
> PyPy, Pyston, Pyjion, Numba, etc. : Hey! it's now time to start to
> take a look at my project and test it ;-) Tell me what is broken, what
> is missing, and I will try to help you to move your project to this
> new benchmark suite!

Also, if you're interested in having your interpreter benchmarked on
speed.python.org, contact me with clear instructions (preferably in
the form of a shell or Python script) on how to build, test, install,
and invoke your interpreter from a fresh Ubuntu 16.04 installation.
As an example, here's an untested version for CPython 3.x:

#!/bin/sh
# set up dependencies
sudo apt-get build-dep -y python3
sudo apt-get install -y --no-install-recommends mercurial
# get the code
hg clone https://hg.python.org/cpython
cd cpython
# build
./configure --prefix=/opt/python/default
make -j12
# test
make buildbottest TESTOPTS=-j12
# install
make install
# invoke
/opt/python/default/bin/python3


I don't know when I'll have a chance to work on it, but I'd like to
get as many projects as possible benchmarked on speed.python.org.

Victor: Thanks for getting the new repository set up and for all your
work on the new runner!  I'm looking forward to trying it out.

-- 
Zach

_______________________________________________
Speed mailing list
https://mail.python.org/mailman/listinfo/speed

From phyo.arkarlwin at gmail.com  Thu Aug 18 06:14:49 2016
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Thu, 18 Aug 2016 10:14:49 +0000
Subject: [pypy-dev] pypy segfault while playing around with odoo.
In-Reply-To: <CAMSv6X0cEjeEvfJBTuMQpHkgZU_z2dR_Uykpu+UfGT51CXK2ig@mail.gmail.com>
References: <CA+HjJrjxLQT0g7hOBmzVhMQf5DETzY63EeR9omoS60=pxbCc7A@mail.gmail.com>
 <CAMSv6X0cEjeEvfJBTuMQpHkgZU_z2dR_Uykpu+UfGT51CXK2ig@mail.gmail.com>
Message-ID: <CA+HjJrirgHuO5T4Tx1xQyCC3Xk_YtsMzgvoAtaqspeJoReC-jQ@mail.gmail.com>

Exactly the same problem.
OS : Linux (Sabayon Linux )
PyPy : 5.3.1
modified requriements.txt :

Babel==1.3
Jinja2==2.7.3
Mako==1.0.1
MarkupSafe==0.23
Pillow==2.7.0
Python-Chart==1.39
PyYAML==3.11
Werkzeug==0.9.6
argparse==1.2.1
decorator==3.4.0
docutils==0.12
feedparser==5.1.3
gdata==2.0.18
gevent>=1.1 #changed
greenlet==0.4.7
jcconv==0.2.3
lxml==3.4.1
mock==1.0.1
ofxparse==0.14
passlib==1.6.2
psutil==2.2.0
psycogreen>=1.0
psycopg2cffi>=2.5.4 #changed
pyPdf==1.13
pydot==1.0.2
pyparsing==2.0.3
pyserial==2.7
python-dateutil==2.4.0
python-ldap==2.4.19
python-openid==2.2.5
pytz==2014.10
pyusb==1.0.0b2
qrcode==5.1
reportlab==3.1.44
requests==2.6.0
six==1.9.0
suds-jurko==0.6
vatnumber==1.2
vobject==0.6.6
wsgiref==0.1.2
xlwt==0.7.5



On Thu, Aug 18, 2016 at 1:25 PM Armin Rigo <arigo at tunes.org> wrote:

> Hi Phyo,
>
> On 16 August 2016 at 20:06, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> > But i got to a stop when creating new db and it crashed with segfault.
>
> Probably the same issue as:
>
> https://bitbucket.org/pypy/pypy/issues/2270/odoo-80-on-pypy-501-cause-segmentation
>
> > How can i debug segfaults in pypy.
>
> http://pypy.readthedocs.io/en/latest/faq.html#how-should-i-report-a-bug
>
>
> Armin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160818/db80ff0d/attachment.html>

From arigo at tunes.org  Thu Aug 18 09:05:13 2016
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 18 Aug 2016 15:05:13 +0200
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
 <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
Message-ID: <CAMSv6X15VqW91Vi-_TNwFDaVN2w3_UTvXg7shyUiksW3LcK6Wg@mail.gmail.com>

Hi William,

On 17 August 2016 at 10:04, William ML Leslie
<william.leslie.ttg at gmail.com> wrote:
> There's code for serialising methods in Django that checks `if
> isinstance(value, (types.FunctionType, types.BuiltinFunctionType))`
> which succeeds on cpython because datetime.date.today is a
> BuiltinFunctionType, wheras it's a types.MethodType on pypy.  Maybe
> that check could be expanded to include MethodType.

Yes, that's the right fix.  The problem is that ``date.today`` returns
a "built-in bound classmethod" object, which on CPython is identified as
``types.BuiltinFunctionType`` but on PyPy is identified as
``types.MethodType``.  We can't add a workaround in PyPy, either:
``date.today`` cannot return a plain function, because ``Date.today``
is a class method, not a static method.


A bient?t,

Armin.

From sergey.forum at gmail.com  Thu Aug 18 22:57:55 2016
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Fri, 19 Aug 2016 05:57:55 +0300
Subject: [pypy-dev] Django DateField default value and migrations fail
In-Reply-To: <CAMSv6X15VqW91Vi-_TNwFDaVN2w3_UTvXg7shyUiksW3LcK6Wg@mail.gmail.com>
References: <CAFVQEu07KEoN9nv7M3smCKDnyPGZ4TjEQt5Ar-t7gVPz-tHW_g@mail.gmail.com>
 <CAHgd1hEsQgMtLkQ-AE1=Bd7SdHzfVaHUrzm+rzDBqJzvS_1u1g@mail.gmail.com>
 <CAFVQEu09hf2jdvHBwLozzZqNHsAUyBZTZ+afyHe3RH3hCai_wg@mail.gmail.com>
 <CAHgd1hEtEP1=JY78ozhW-_p1i-9uG5kLn+4k9DCXrXm7w+YWAA@mail.gmail.com>
 <CAMSv6X15VqW91Vi-_TNwFDaVN2w3_UTvXg7shyUiksW3LcK6Wg@mail.gmail.com>
Message-ID: <CAFVQEu2QGtrnC2N4nKU0rxHcSBCA-1nBakFtT3boyxKs5_tfTw@mail.gmail.com>

Hi All,

after submitting a ticket

a fix to Django is submitted by Django developer

https://github.com/django/django/pull/7113

hope it will be in next Django release.

Regards
Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160819/d2367e52/attachment.html>

From matti.picus at gmail.com  Wed Aug 24 04:44:04 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 24 Aug 2016 18:44:04 +1000
Subject: [pypy-dev] PyPy 5.4 release beginning
Message-ID: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>

Hi. I would like to release PyPy2 v5.4. There is one failing test on 
linux64 which has to do with test_setrlimit() on bencher4. Are there any 
other release blockers? Branches to be merged?

Matti

From arigo at tunes.org  Wed Aug 24 06:16:50 2016
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 24 Aug 2016 12:16:50 +0200
Subject: [pypy-dev] PyPy 5.4 release beginning
In-Reply-To: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
Message-ID: <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>

Hi Matti,

On 24 August 2016 at 10:44, Matti Picus <matti.picus at gmail.com> wrote:
> Hi. I would like to release PyPy2 v5.4. There is one failing test on linux64
> which has to do with test_setrlimit() on bencher4.

Did you mean on the OS/X 64 buildslave?  Should be fixed in 6bfe423a36a4.

> Are there any other release blockers? Branches to be merged?

There are a few branches around but I think that they are not ready to
be merged to default, as far as I can tell.


Armin

From matti.picus at gmail.com  Wed Aug 24 08:08:06 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 24 Aug 2016 22:08:06 +1000
Subject: [pypy-dev] PyPy 5.4 release beginning
In-Reply-To: <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
Message-ID: <5377f245-4234-b261-1905-c7978cb757d9@gmail.com>



On 24/08/16 20:16, Armin Rigo wrote:
> Hi Matti,
>
> On 24 August 2016 at 10:44, Matti Picus <matti.picus at gmail.com> wrote:
>> Hi. I would like to release PyPy2 v5.4. There is one failing test on linux64
>> which has to do with test_setrlimit() on bencher4.
> Did you mean on the OS/X 64 buildslave?  Should be fixed in 6bfe423a36a4.
>
> \Armin 

I meant this one, failing for a few days now
http://buildbot.pypy.org/summary/longrepr?testname=&builder=pypy-c-jit-linux-x86-64&build=3709&mod=module%2Ftest_lib_pypy
as can be seem on the summary for linux-x86-64 on default
http://buildbot.pypy.org/summary?builder=pypy-c-jit-linux-x86-64&branch=default

I tracked this down to the test_setrlimit() test in 
test_lib_pypy/test_resources.py, skipping that test removes the SIGKILL 
failure
Matti

From arigo at tunes.org  Wed Aug 24 11:57:48 2016
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 24 Aug 2016 17:57:48 +0200
Subject: [pypy-dev] PyPy 5.4 release beginning
In-Reply-To: <5377f245-4234-b261-1905-c7978cb757d9@gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
 <5377f245-4234-b261-1905-c7978cb757d9@gmail.com>
Message-ID: <CAMSv6X25AQE_eH-XNeAMs63kGPfOxZt7bZPVaUdC0Zg84ASfww@mail.gmail.com>

Hi Matti,

On 24 August 2016 at 14:08, Matti Picus <matti.picus at gmail.com> wrote:
> I meant this one, failing for a few days now
> http://buildbot.pypy.org/summary/longrepr?testname=&builder=pypy-c-jit-linux-x86-64&build=3709&mod=module%2Ftest_lib_pypy
> as can be seem on the summary for linux-x86-64 on default
> http://buildbot.pypy.org/summary?builder=pypy-c-jit-linux-x86-64&branch=default
>
> I tracked this down to the test_setrlimit() test in
> test_lib_pypy/test_resources.py, skipping that test removes the SIGKILL
> failure

Ah.  As it turns out, the fix I did for OS/X applies here too.  It
should work from the next run, hopefully.  (It got a crash because it
called set_rlimit() with (0, 0), which instantly killed the process
because it was using more than 0 seconds of CPU.)


A bient?t,

Armin.

From matti.picus at gmail.com  Sun Aug 28 19:14:31 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 29 Aug 2016 09:14:31 +1000
Subject: [pypy-dev] PyPy 5.4 release
In-Reply-To: <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
Message-ID: <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>

The builds are ready and buildbots green (enough IMO).
http://buildbot.pypy.org/nightly/release-5.x, any of the 
86635-77392ad26350 binaries should be good to go.
Please download and test them, especially the OSX and ARM ones.

Anyone who is proficient with scipy/pandas/matplotlib could try their 
test suites out, upstream numpy should install on all platforms although 
there are known shortcomings with new buffer interface compatibility.

I will be unable to repackage and upload to bitbucket for the next few 
days, so if anyone with fast internet can run the repackages script it 
would be very helpful:
- update your pypy repo on linux
- create a tmp directory anywhere in the repo
- run pypy/tools/release/repackage.sh
- upload the resulting 10 binary packages (8 precompiled, 2 source) to 
bitbucket/pypy/pypy/downloads
- update pypy.org/downloads with the hashes printed out at the end of 
the script, or post them here

We do not have ppc builds, so those would be helpful too.

Thanks, and thanks to the team for pushing PyPy forward!
Matti


From arigo at tunes.org  Mon Aug 29 07:15:49 2016
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 29 Aug 2016 13:15:49 +0200
Subject: [pypy-dev] PyPy 5.4 release
In-Reply-To: <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
 <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
Message-ID: <CAMSv6X05EFV5iUFwht50jesVY5SMDbceUmM6-BV8pABSfk+gVQ@mail.gmail.com>

Hi Matti,

On 29 August 2016 at 01:14, Matti Picus <matti.picus at gmail.com> wrote:
> The builds are ready and buildbots green (enough IMO).
> http://buildbot.pypy.org/nightly/release-5.x, any of the 86635-77392ad26350
> binaries should be good to go.
> Please download and test them, especially the OSX and ARM ones.

Thanks for the work!

The hg tag you created: "Added tag release-pypy2.7-v5.4.0 for
changeset 68bb3510d821", is a changeset from default.  Is that
expected?  Didn't you mean to use 77392ad26350?

> We do not have ppc builds, so those would be helpful too.

I'm building them now.


A bient?t,

Armin.

From matti.picus at gmail.com  Mon Aug 29 07:56:50 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 29 Aug 2016 21:56:50 +1000
Subject: [pypy-dev] PyPy 5.4 release
In-Reply-To: <CAMSv6X05EFV5iUFwht50jesVY5SMDbceUmM6-BV8pABSfk+gVQ@mail.gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
 <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
 <CAMSv6X05EFV5iUFwht50jesVY5SMDbceUmM6-BV8pABSfk+gVQ@mail.gmail.com>
Message-ID: <45234135-ba94-34dc-ac07-bb9f86cf1e0d@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160829/e69e2f51/attachment.html>

From peter.xihong.wang at intel.com  Mon Aug 29 19:52:17 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Mon, 29 Aug 2016 23:52:17 +0000
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy source
 code build faster?
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>

Hi,

By default, it appears most of the time during the build/compile process, only 1 single CPU core is busy, signaling missing of parallel compiling.   Is there any best known practice to make it faster?

Thanks,

Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160829/2367bd1b/attachment.html>

From william.leslie.ttg at gmail.com  Mon Aug 29 20:07:43 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Tue, 30 Aug 2016 10:07:43 +1000
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
Message-ID: <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>

On 30/08/2016 9:53 am, "Wang, Peter Xihong" <peter.xihong.wang at intel.com>
wrote:
>
> Hi,
>
>
>
> By default, it appears most of the time during the build/compile process,
only 1 single CPU core is busy, signaling missing of parallel compiling.
  Is there any best known practice to make it faster?
>
>

Not at the moment. The STM work that Armin is doing may give us an
interpreter that can make better use of extra cores during translation, but
it is still experimental.

>
> Thanks,
>
>
>
> Peter
>
>
>
>
>
>
> _______________________________________________
> 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/20160830/5ba92084/attachment.html>

From arigo at tunes.org  Tue Aug 30 12:10:49 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 30 Aug 2016 18:10:49 +0200
Subject: [pypy-dev] PyPy 5.4 release
In-Reply-To: <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
 <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
Message-ID: <CAMSv6X0JaNVOjLK12i0UPOq3CRkJHnnkftjvd7tCyZW+pvds1A@mail.gmail.com>

Hi Matti,

On 29 August 2016 at 01:14, Matti Picus <matti.picus at gmail.com> wrote:
> I will be unable to repackage and upload to bitbucket for the next few days,
> so if anyone with fast internet can run the repackages script it would be
> very helpful:

Done!  I've also uploaded the ppc builds.  All the hashes are in
source/download.txt.


A bient?t,

Armin.

From dje.gcc at gmail.com  Tue Aug 30 12:54:55 2016
From: dje.gcc at gmail.com (David Edelsohn)
Date: Tue, 30 Aug 2016 12:54:55 -0400
Subject: [pypy-dev] PyPy 5.4 release
In-Reply-To: <CAMSv6X0JaNVOjLK12i0UPOq3CRkJHnnkftjvd7tCyZW+pvds1A@mail.gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
 <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
 <CAMSv6X0JaNVOjLK12i0UPOq3CRkJHnnkftjvd7tCyZW+pvds1A@mail.gmail.com>
Message-ID: <CAGWvny=O1RBbHO=ppgo925QKuxUPh=hHXKw9P8k4S+sAcr8JmA@mail.gmail.com>

On Tue, Aug 30, 2016 at 12:10 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Matti,
>
> On 29 August 2016 at 01:14, Matti Picus <matti.picus at gmail.com> wrote:
>> I will be unable to repackage and upload to bitbucket for the next few days,
>> so if anyone with fast internet can run the repackages script it would be
>> very helpful:
>
> Done!  I've also uploaded the ppc builds.  All the hashes are in
> source/download.txt.

Thanks!

- David

From matti.picus at gmail.com  Tue Aug 30 22:12:31 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 31 Aug 2016 05:12:31 +0300
Subject: [pypy-dev] PyPy 5.4 release
In-Reply-To: <CAMSv6X0JaNVOjLK12i0UPOq3CRkJHnnkftjvd7tCyZW+pvds1A@mail.gmail.com>
References: <3549bd11-fc89-b2d6-df63-65dbd5cb924b@gmail.com>
 <CAMSv6X34P5xciHbGnZePr=-P67iYgYdz8HuXmyZdSKTMr5bzuw@mail.gmail.com>
 <5885c582-e27d-5670-a68f-0d75a1474ab5@gmail.com>
 <CAMSv6X0JaNVOjLK12i0UPOq3CRkJHnnkftjvd7tCyZW+pvds1A@mail.gmail.com>
Message-ID: <c657415c-2513-231e-78a9-f695b0b5ea06@gmail.com>




On 30/08/16 19:10, Armin Rigo wrote:
> Hi Matti,
>
> On 29 August 2016 at 01:14, Matti Picus <matti.picus at gmail.com> wrote:
>> I will be unable to repackage and upload to bitbucket for the next few days,
>> so if anyone with fast internet can run the repackages script it would be
>> very helpful:
> Done!  I've also uploaded the ppc builds.  All the hashes are in
> source/download.txt.
>
>
> A bient?t,
>
> Armin.
Thanks. Please test the release binaries available at

https://bitbucket.org/pypy/pypy/downloads.

If no-one complains in the next day or so I will finish the release.
Matti