From sergey.forum at gmail.com  Sat Apr  1 07:57:45 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Sat, 1 Apr 2017 14:57:45 +0300
Subject: [pypy-dev]  Visual Studio 2015 build strange behavior
Message-ID: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>

Hi,

I managed to build pypy with visual studio 2015 ( win32 build on window
10/64 )
with both python and by pypy itself
but I have one strange behavior
it manifest in a first steps using new pypy by running pip

pypy-c -mpip install -U wheel

and an error reads

  Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after
connection broken by
'NewConnectionError('<pip._vendor.requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x042cd170>: Failed to establish a new connection: [Errno 10035]
A non-blocking socket operation could not be completed immediately',)':
/simple/whe

exactly error is: [Errno 10035] A non-blocking socket operation could not
be completed immediately'

( the same error [Errno 10035] A non-blocking socket operation could not be
completed immediately', also appears if I try to use PyMySQL driver to
connect to mysql , so this is not that something happened to pip repository)

the reason I built with Visual Studio 2015 was that stock pypy for windows
would crash on my projects - and I have visual studio 2015.
the build I obtained also seems somewhat more stable to my eyes, so it
worth the try.

but now I have seemingly more stable pypy, but at the same time that
network error, any hints what might be involved here and how to debug?

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

From armin.rigo at gmail.com  Sun Apr  2 04:03:47 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Sun, 2 Apr 2017 10:03:47 +0200
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
Message-ID: <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>

Hi Sergey,

On 1 April 2017 at 13:57, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
> but now I have seemingly more stable pypy, but at the same time that network
> error, any hints what might be involved here and how to debug?

As an aside, we'd love to get any precise information about
"unstabilities" of the standard PyPy.

We need precise information, though.  We can't help much with what you
said so far.  Maybe some issue like the C-level connect() function
that behaves differently when built with another version of Visual
Studio?  As a starting point, try to reproduce the problem in a few
lines of code, which is usually a good way to get a hint about what is
wrong.


A bient?t,

Armin.

From nanjekyejoannah at gmail.com  Sun Apr  2 04:50:41 2017
From: nanjekyejoannah at gmail.com (joannah nanjekye)
Date: Sun, 2 Apr 2017 11:50:41 +0300
Subject: [pypy-dev] Details on project idea: Explicit typing in RPython
In-Reply-To: <CANFMCgQUGkn44zfjBOyJuTxUTwNxNgVzkofhGYjOsps+UQnLwA@mail.gmail.com>
References: <CANFMCgQhk-rLDsrD9JMPxaZ8RthwjWyRKw-=vLxGTtXkxWzNHA@mail.gmail.com>
 <7cc2c179-d09c-9615-aac8-1b0fb06b66f4@gmail.com>
 <CAO41-mMh4u4oabWfE9Cd5XHUzOnVgOH_0ax4euFA=4agKR26nQ@mail.gmail.com>
 <a5a7335d-f595-9f3a-8a4a-ce42044eede0@gmail.com>
 <CANFMCgQUGkn44zfjBOyJuTxUTwNxNgVzkofhGYjOsps+UQnLwA@mail.gmail.com>
Message-ID: <CANFMCgSyxem51k8r9EidDwUhnuVqOogaD3xLtAti72LMSo4o1Q@mail.gmail.com>

Hello

It is kinda last minute but if some one has a minute, kindly give me some
feedback for my GSoC proposal here
https://docs.google.com/document/d/1tidHKzTWOLDILPsUag8Vc0aS-lsIzwHDYvuGQ-hRAJg/edit
before I submit.

Kind regards,

On Fri, Mar 31, 2017 at 1:44 PM, joannah nanjekye <nanjekyejoannah at gmail.com
> wrote:

> Thank you I think this is clearer to me now.
>
>
> On Wed, Mar 29, 2017 at 6:34 PM, Ronan Lamy <ronan.lamy at gmail.com> wrote:
>
>> Le 29/03/17 ? 15:28, Ryan Gonzalez a ?crit :
>>
>>> RPython already has this:
>>>
>>>
>>> https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/signature.py
>>>
>>
>> Indeed, @signature is one of 2 prior attempts at doing this in
>> rpython[*]. However its syntax is cumbersome and it's rather limited in the
>> types it can express - you can only use what's in rpython.rlib.types and
>> these functions cannot be combined arbitrarily to build more complex types.
>>
>> [*] The other one is @enforceargs: https://bitbucket.org/pypy/pyp
>> y/src/tip/rpython/rlib/objectmodel.py
>>
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> Joannah Nanjekye
> +256776468213 <+256%20776%20468213>
> F : Nanjekye Captain Joannah
> S : joannah.nanjekye
> T : @captainjoannah
> SO : joannah
>
>
> *"You think you know when you learn, are more sure when you can write,
> even more when you can teach, but certain when you can program." Alan J.
> Perlis*
>



-- 
Joannah Nanjekye
+256776468213
F : Nanjekye Captain Joannah
S : joannah.nanjekye
T : @captainjoannah
SO : joannah


*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170402/51b55475/attachment.html>

From sergey.forum at gmail.com  Sun Apr  2 05:56:41 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Sun, 2 Apr 2017 12:56:41 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
Message-ID: <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>

Hi Armin,

>As an aside, we'd love to get any precise information about
>"unstabilities" of the standard PyPy.

the precise instability is that stock installation crashes on my project (
unfortunately it is too big to catch for me - so that
I try to compile some custom version and find out )

>We need precise information, though.  We can't help much with what you
>said so far.

so far I narrowed that I reimplemented _PyVerify_fd() ( which does not
compile in VS2015 ) and did it wrong.

fortunately I found some code in ruby which implements requesting pioinfo
in VS2015 - will try that.
Then will report of progress if I have some.

Regards
Sergey



On Sun, Apr 2, 2017 at 11:03 AM, Armin Rigo <armin.rigo at gmail.com> wrote:

> Hi Sergey,
>
> On 1 April 2017 at 13:57, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
> > but now I have seemingly more stable pypy, but at the same time that
> network
> > error, any hints what might be involved here and how to debug?
>
> As an aside, we'd love to get any precise information about
> "unstabilities" of the standard PyPy.
>
> We need precise information, though.  We can't help much with what you
> said so far.  Maybe some issue like the C-level connect() function
> that behaves differently when built with another version of Visual
> Studio?  As a starting point, try to reproduce the problem in a few
> lines of code, which is usually a good way to get a hint about what is
> wrong.
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170402/430af9b3/attachment.html>

From cfbolz at gmx.de  Sun Apr  2 06:13:59 2017
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 02 Apr 2017 12:13:59 +0200
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
Message-ID: <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>

Hi Sergey, 

Thanks a lot for trying to look into this! Some more windows expertise is very welcome.

Cheers,

Carl Friedrich 

On April 2, 2017 11:56:41 AM GMT+02:00, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
>Hi Armin,
>
>>As an aside, we'd love to get any precise information about
>>"unstabilities" of the standard PyPy.
>
>the precise instability is that stock installation crashes on my
>project (
>unfortunately it is too big to catch for me - so that
>I try to compile some custom version and find out )
>
>>We need precise information, though.  We can't help much with what you
>>said so far.
>
>so far I narrowed that I reimplemented _PyVerify_fd() ( which does not
>compile in VS2015 ) and did it wrong.
>
>fortunately I found some code in ruby which implements requesting
>pioinfo
>in VS2015 - will try that.
>Then will report of progress if I have some.
>
>Regards
>Sergey
>
>
>
>On Sun, Apr 2, 2017 at 11:03 AM, Armin Rigo <armin.rigo at gmail.com>
>wrote:
>
>> Hi Sergey,
>>
>> On 1 April 2017 at 13:57, Sergey Kurdakov <sergey.forum at gmail.com>
>wrote:
>> > but now I have seemingly more stable pypy, but at the same time
>that
>> network
>> > error, any hints what might be involved here and how to debug?
>>
>> As an aside, we'd love to get any precise information about
>> "unstabilities" of the standard PyPy.
>>
>> We need precise information, though.  We can't help much with what
>you
>> said so far.  Maybe some issue like the C-level connect() function
>> that behaves differently when built with another version of Visual
>> Studio?  As a starting point, try to reproduce the problem in a few
>> lines of code, which is usually a good way to get a hint about what
>is
>> wrong.
>>
>>
>> A bient?t,
>>
>> Armin.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170402/7092b96a/attachment-0001.html>

From matti.picus at gmail.com  Sun Apr  2 15:22:30 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Sun, 2 Apr 2017 22:22:30 +0300
Subject: [pypy-dev] 5.7.1 bug fix release
Message-ID: <a286df49-8ae8-665a-c91b-2dd2c22757da@gmail.com>

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

From dynamicgl at gmail.com  Mon Apr  3 02:42:21 2017
From: dynamicgl at gmail.com (Gelin Yan)
Date: Mon, 3 Apr 2017 14:42:21 +0800
Subject: [pypy-dev] 5.7.1 bug fix release
In-Reply-To: <a286df49-8ae8-665a-c91b-2dd2c22757da@gmail.com>
References: <a286df49-8ae8-665a-c91b-2dd2c22757da@gmail.com>
Message-ID: <CABkOF6SK7L7u0hrQQx75+-8TDNLKLfVcdJRZBw-hzTkpcsK+ag@mail.gmail.com>

Hi Matti

   Thanks. The website is still pointing to 5.7.0

Regards

gelin yan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170403/c4c24295/attachment.html>

From planrichi at gmail.com  Mon Apr  3 11:01:10 2017
From: planrichi at gmail.com (Richard Plangger)
Date: Mon, 3 Apr 2017 11:01:10 -0400
Subject: [pypy-dev] Details on project idea: Explicit typing in RPython
In-Reply-To: <CANFMCgSyxem51k8r9EidDwUhnuVqOogaD3xLtAti72LMSo4o1Q@mail.gmail.com>
References: <CANFMCgQhk-rLDsrD9JMPxaZ8RthwjWyRKw-=vLxGTtXkxWzNHA@mail.gmail.com>
 <7cc2c179-d09c-9615-aac8-1b0fb06b66f4@gmail.com>
 <CAO41-mMh4u4oabWfE9Cd5XHUzOnVgOH_0ax4euFA=4agKR26nQ@mail.gmail.com>
 <a5a7335d-f595-9f3a-8a4a-ce42044eede0@gmail.com>
 <CANFMCgQUGkn44zfjBOyJuTxUTwNxNgVzkofhGYjOsps+UQnLwA@mail.gmail.com>
 <CANFMCgSyxem51k8r9EidDwUhnuVqOogaD3xLtAti72LMSo4o1Q@mail.gmail.com>
Message-ID: <3c21191d-906f-6418-e7b7-b308e03d82b5@gmail.com>

Hi,

I would suggest to change the deliverables. We already have a way to
specify the type for function signatures (mentioned in this email
thread). It should at least mention that you extend those. It would be
also very useful if you kind of gave an example how the mini language
(e.g. specified in the doc string) would look like. Could we maybe use
mypy for that? In the end that is an open question .. (to be solved by
you :)

If I'm correct you got 1h left to change the document!!

Cheers,
Richard

On 04/02/2017 04:50 AM, joannah nanjekye wrote:
> Hello
> 
> It is kinda last minute but if some one has a minute, kindly give me
> some feedback for my GSoC proposal here
> https://docs.google.com/document/d/1tidHKzTWOLDILPsUag8Vc0aS-lsIzwHDYvuGQ-hRAJg/edit
> before I submit.
> 
> Kind regards,
> 
> On Fri, Mar 31, 2017 at 1:44 PM, joannah nanjekye
> <nanjekyejoannah at gmail.com <mailto:nanjekyejoannah at gmail.com>> wrote:
> 
>     Thank you I think this is clearer to me now.
> 
> 
>     On Wed, Mar 29, 2017 at 6:34 PM, Ronan Lamy <ronan.lamy at gmail.com
>     <mailto:ronan.lamy at gmail.com>> wrote:
> 
>         Le 29/03/17 ? 15:28, Ryan Gonzalez a ?crit :
> 
>             RPython already has this:
> 
> 
>             https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/signature.py
>             <https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/signature.py>
> 
> 
>         Indeed, @signature is one of 2 prior attempts at doing this in
>         rpython[*]. However its syntax is cumbersome and it's rather
>         limited in the types it can express - you can only use what's in
>         rpython.rlib.types and these functions cannot be combined
>         arbitrarily to build more complex types.
> 
>         [*] The other one is @enforceargs:
>         https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/objectmodel.py
>         <https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/objectmodel.py>
> 
>         _______________________________________________
>         pypy-dev mailing list
>         pypy-dev at python.org <mailto:pypy-dev at python.org>
>         https://mail.python.org/mailman/listinfo/pypy-dev
>         <https://mail.python.org/mailman/listinfo/pypy-dev>
> 
> 
> 
> 
>     -- 
>     //Joannah Nanjekye
>     +256776468213 <tel:+256%20776%20468213>
>     F : Nanjekye Captain Joannah
>     S : joannah.nanjekye
>     T : @captainjoannah
>     SO : joannah
> 
>     /"You think you know when you learn, are more sure when you can
>     write, even more when you can teach, but certain when you can program."
>     Alan J. Perlis/
> 
> 
> 
> 
> -- 
> //Joannah Nanjekye
> +256776468213
> F : Nanjekye Captain Joannah
> S : joannah.nanjekye
> T : @captainjoannah
> SO : joannah
> 
> /"You think you know when you learn, are more sure when you can write,
> even more when you can teach, but certain when you can program."
> Alan J. Perlis/
> 
> 
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
> 

From nanjekyejoannah at gmail.com  Mon Apr  3 11:53:34 2017
From: nanjekyejoannah at gmail.com (joannah nanjekye)
Date: Mon, 3 Apr 2017 18:53:34 +0300
Subject: [pypy-dev] Details on project idea: Explicit typing in RPython
In-Reply-To: <3c21191d-906f-6418-e7b7-b308e03d82b5@gmail.com>
References: <CANFMCgQhk-rLDsrD9JMPxaZ8RthwjWyRKw-=vLxGTtXkxWzNHA@mail.gmail.com>
 <7cc2c179-d09c-9615-aac8-1b0fb06b66f4@gmail.com>
 <CAO41-mMh4u4oabWfE9Cd5XHUzOnVgOH_0ax4euFA=4agKR26nQ@mail.gmail.com>
 <a5a7335d-f595-9f3a-8a4a-ce42044eede0@gmail.com>
 <CANFMCgQUGkn44zfjBOyJuTxUTwNxNgVzkofhGYjOsps+UQnLwA@mail.gmail.com>
 <CANFMCgSyxem51k8r9EidDwUhnuVqOogaD3xLtAti72LMSo4o1Q@mail.gmail.com>
 <3c21191d-906f-6418-e7b7-b308e03d82b5@gmail.com>
Message-ID: <CANFMCgT5x_gbuGk-Qv9=bO4vTy9ymh+xsY=59YAMLgqSBgq_9g@mail.gmail.com>

Thanks for taking time to give me feedback. I have tried to make the
necessary changes swiftly(last minute). I hope I dint misrepresent alot.

Kind regards,
joannah

On Mon, Apr 3, 2017 at 6:01 PM, Richard Plangger <planrichi at gmail.com>
wrote:

> Hi,
>
> I would suggest to change the deliverables. We already have a way to
> specify the type for function signatures (mentioned in this email
> thread). It should at least mention that you extend those. It would be
> also very useful if you kind of gave an example how the mini language
> (e.g. specified in the doc string) would look like. Could we maybe use
> mypy for that? In the end that is an open question .. (to be solved by
> you :)
>
> If I'm correct you got 1h left to change the document!!
>
> Cheers,
> Richard
>
> On 04/02/2017 04:50 AM, joannah nanjekye wrote:
> > Hello
> >
> > It is kinda last minute but if some one has a minute, kindly give me
> > some feedback for my GSoC proposal here
> > https://docs.google.com/document/d/1tidHKzTWOLDILPsUag8Vc0aS-
> lsIzwHDYvuGQ-hRAJg/edit
> > before I submit.
> >
> > Kind regards,
> >
> > On Fri, Mar 31, 2017 at 1:44 PM, joannah nanjekye
> > <nanjekyejoannah at gmail.com <mailto:nanjekyejoannah at gmail.com>> wrote:
> >
> >     Thank you I think this is clearer to me now.
> >
> >
> >     On Wed, Mar 29, 2017 at 6:34 PM, Ronan Lamy <ronan.lamy at gmail.com
> >     <mailto:ronan.lamy at gmail.com>> wrote:
> >
> >         Le 29/03/17 ? 15:28, Ryan Gonzalez a ?crit :
> >
> >             RPython already has this:
> >
> >
> >             https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/
> signature.py
> >             <https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/
> signature.py>
> >
> >
> >         Indeed, @signature is one of 2 prior attempts at doing this in
> >         rpython[*]. However its syntax is cumbersome and it's rather
> >         limited in the types it can express - you can only use what's in
> >         rpython.rlib.types and these functions cannot be combined
> >         arbitrarily to build more complex types.
> >
> >         [*] The other one is @enforceargs:
> >         https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/
> objectmodel.py
> >         <https://bitbucket.org/pypy/pypy/src/tip/rpython/rlib/
> objectmodel.py>
> >
> >         _______________________________________________
> >         pypy-dev mailing list
> >         pypy-dev at python.org <mailto:pypy-dev at python.org>
> >         https://mail.python.org/mailman/listinfo/pypy-dev
> >         <https://mail.python.org/mailman/listinfo/pypy-dev>
> >
> >
> >
> >
> >     --
> >     //Joannah Nanjekye
> >     +256776468213 <tel:+256%20776%20468213>
> >     F : Nanjekye Captain Joannah
> >     S : joannah.nanjekye
> >     T : @captainjoannah
> >     SO : joannah
> >
> >     /"You think you know when you learn, are more sure when you can
> >     write, even more when you can teach, but certain when you can
> program."
> >     Alan J. Perlis/
> >
> >
> >
> >
> > --
> > //Joannah Nanjekye
> > +256776468213
> > F : Nanjekye Captain Joannah
> > S : joannah.nanjekye
> > T : @captainjoannah
> > SO : joannah
> >
> > /"You think you know when you learn, are more sure when you can write,
> > even more when you can teach, but certain when you can program."
> > Alan J. Perlis/
> >
> >
> > _______________________________________________
> > pypy-dev mailing list
> > pypy-dev at python.org
> > https://mail.python.org/mailman/listinfo/pypy-dev
> >
>



-- 
Joannah Nanjekye
+256776468213
F : Nanjekye Captain Joannah
S : joannah.nanjekye
T : @captainjoannah
SO : joannah


*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170403/18862cd1/attachment-0001.html>

From sergey.forum at gmail.com  Tue Apr  4 01:43:03 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Tue, 4 Apr 2017 08:43:03 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
Message-ID: <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>

Hi,

for anyone interested here are my changes to compile with VS2015 compiler
in attachment (over pypy version  5.7.1)

I compiled with stock python

cd pypy/goalpython  ../../rpython/bin/rpython --opt=jit

compilation options in files are changed manually to reflect new compiler

rpython\translator\platform\windows.py

in _get_msvc_env(vsver, x64flag)
toolsdir = os.environ['VS140COMNTOOLS']

vcvars = "C:\\Program Files (x86)\\Microsoft Visual Studio
14.0\\Common7\\Tools\\vsvars32.bat"#os.path.join(toolsdir, 'vsvars32.bat')

otherwise - I followed http://doc.pypy.org/en/latest/windows.html

few caveats:
VS2015 now loads ucrtbase.dll in place of msvcrt.dll

changed _PyVerify_fd implementation as it won't compile,
fixed few other compilation issues.

the compilation works, but all network calls end with
[Errno 10035] A non-blocking socket operation could not be completed
immediately ( but _PyVerify_fd works correctly )

did not figure  out so far why  it happens.

while changes are not production ready - they could be a hint what might be
needed to change in pypy to compile with new
ms compilers ( ucrtbase vs msvcrt etc, new _PyVerify_fd etc )

attachment is a zip file with changed extension ( gmail checks for py files
.... ) and contains only changed files (pypy 5.7.1)

Now I will try older compilers to see if I could catch my initial crash
with python project, but in a few weeks time.
Still think, that it is ok to share changes - someone could try and see
what is needed for future support of vs2015/vs2017

Best regards
Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170404/c107b2cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy571_msvc14_changes.zip_archive_change_to_zip
Type: application/octet-stream
Size: 413439 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170404/c107b2cb/attachment-0001.obj>

From phyo.arkarlwin at gmail.com  Tue Apr  4 07:35:14 2017
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Tue, 04 Apr 2017 11:35:14 +0000
Subject: [pypy-dev] 5.7.1 bug fix release
In-Reply-To: <CABkOF6SK7L7u0hrQQx75+-8TDNLKLfVcdJRZBw-hzTkpcsK+ag@mail.gmail.com>
References: <a286df49-8ae8-665a-c91b-2dd2c22757da@gmail.com>
 <CABkOF6SK7L7u0hrQQx75+-8TDNLKLfVcdJRZBw-hzTkpcsK+ag@mail.gmail.com>
Message-ID: <CA+HjJrjbNQuc=qXAY-26gL0eH3=bzegp3_AtiSsnkw27NJzvcA@mail.gmail.com>

So i read ,
the 3.5 version is still considered beta?
What are missing / known issue for 3.5 now ?

On Mon, Apr 3, 2017 at 1:14 PM Gelin Yan <dynamicgl at gmail.com> wrote:

> Hi Matti
>
>    Thanks. The website is still pointing to 5.7.0
>
> Regards
>
> gelin yan
> _______________________________________________
> 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/20170404/0c9e4927/attachment.html>

From frankw at mit.edu  Tue Apr  4 11:31:22 2017
From: frankw at mit.edu (Frank Wang)
Date: Tue, 4 Apr 2017 11:31:22 -0400
Subject: [pypy-dev] Debugging SegFaults
Message-ID: <CAD=7XjPLEPeB4pfLJrhTKB9ZLq7FXzhp_aeQcfbZHgyHhJSu2Q@mail.gmail.com>

Hi,

I made some modifications to pypy, but the new pypy-c binary results in a
segfault on certain instructions. What's the easiest way to do a traceback
to see what led to the segfault?

Thanks,
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170404/8d03fc5e/attachment.html>

From florin.papa at intel.com  Tue Apr  4 13:35:21 2017
From: florin.papa at intel.com (Papa, Florin)
Date: Tue, 4 Apr 2017 17:35:21 +0000
Subject: [pypy-dev] Debugging SegFaults
In-Reply-To: <CAD=7XjPLEPeB4pfLJrhTKB9ZLq7FXzhp_aeQcfbZHgyHhJSu2Q@mail.gmail.com>
References: <CAD=7XjPLEPeB4pfLJrhTKB9ZLq7FXzhp_aeQcfbZHgyHhJSu2Q@mail.gmail.com>
Message-ID: <3A375A669FBEFF45B6B60E689636EDCA0B02E4DC@ORSMSX110.amr.corp.intel.com>

Hi Frank,

You would need to compile pypy with ?--lldebug?, then run your workload in GDB to see where it crashes. Another option is to obtain a core dump (if you cannot run the workload directly in GDB), then analyze the core dump in GDB. Please see [1] and [2] for this.

[1] http://stackoverflow.com/questions/6152232/how-to-generate-core-dump-file-in-ubuntu
[2] http://stackoverflow.com/questions/8305866/how-to-analyze-a-programs-core-dump-file-with-gdb

Regards,
Florin

From: pypy-dev [mailto:pypy-dev-bounces+florin.papa=intel.com at python.org] On Behalf Of Frank Wang
Sent: Tuesday, April 4, 2017 8:31 AM
To: PyPy Developer Mailing List <pypy-dev at python.org>
Subject: [pypy-dev] Debugging SegFaults

Hi,

I made some modifications to pypy, but the new pypy-c binary results in a segfault on certain instructions. What's the easiest way to do a traceback to see what led to the segfault?

Thanks,
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170404/e1897881/attachment.html>

From armin.rigo at gmail.com  Wed Apr  5 06:45:08 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Wed, 5 Apr 2017 12:45:08 +0200
Subject: [pypy-dev] Debugging SegFaults
In-Reply-To: <CAD=7XjPLEPeB4pfLJrhTKB9ZLq7FXzhp_aeQcfbZHgyHhJSu2Q@mail.gmail.com>
References: <CAD=7XjPLEPeB4pfLJrhTKB9ZLq7FXzhp_aeQcfbZHgyHhJSu2Q@mail.gmail.com>
Message-ID: <CAMSv6X0697A60RknyfMTWyXT0dZxf-uhQV9Vc19riU13fbHs-Q@mail.gmail.com>

Hi,

On 4 April 2017 at 17:31, Frank Wang <frankw at mit.edu> wrote:
> I made some modifications to pypy, but the new pypy-c binary results in a
> segfault on certain instructions. What's the easiest way to do a traceback
> to see what led to the segfault?

There's also "pypy -X faulthandler" if all you're interested in
knowing which Python line causes the segfault.  It was backported from
CPython 3.x to both PyPy3 and PyPy2.


A bient?t,

Armin.

From sergey.forum at gmail.com  Wed Apr  5 08:58:21 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 5 Apr 2017 15:58:21 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
Message-ID: <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>

Hi,

btw seems I got why error 10035 appears in VS 2015 build network calls,

in pypy code there is check for EWOULDBLOCK and required steps are made
to deal with situation.

but in VS 2015 EWOULDBLOCK is defined as

#define EWOULDBLOCK     140

while 10035 error is defined as

#define WSAEWOULDBLOCK                   10035L

so all code logic  checking real EWOULDBLOCK is misused by pypy compiled
with VS 2015

now will try to play  with that new definition, possibly code will start to
make socket calls in VS 2015.

Regards
Sergey

On Tue, Apr 4, 2017 at 8:43 AM, Sergey Kurdakov <sergey.forum at gmail.com>
wrote:

> Hi,
>
> for anyone interested here are my changes to compile with VS2015 compiler
> in attachment (over pypy version  5.7.1)
>
> I compiled with stock python
>
> cd pypy/goalpython  ../../rpython/bin/rpython --opt=jit
>
> compilation options in files are changed manually to reflect new compiler
>
> rpython\translator\platform\windows.py
>
> in _get_msvc_env(vsver, x64flag)
> toolsdir = os.environ['VS140COMNTOOLS']
>
> vcvars = "C:\\Program Files (x86)\\Microsoft Visual Studio
> 14.0\\Common7\\Tools\\vsvars32.bat"#os.path.join(toolsdir, 'vsvars32.bat')
>
> otherwise - I followed http://doc.pypy.org/en/latest/windows.html
>
> few caveats:
> VS2015 now loads ucrtbase.dll in place of msvcrt.dll
>
> changed _PyVerify_fd implementation as it won't compile,
> fixed few other compilation issues.
>
> the compilation works, but all network calls end with
> [Errno 10035] A non-blocking socket operation could not be completed
> immediately ( but _PyVerify_fd works correctly )
>
> did not figure  out so far why  it happens.
>
> while changes are not production ready - they could be a hint what might
> be needed to change in pypy to compile with new
> ms compilers ( ucrtbase vs msvcrt etc, new _PyVerify_fd etc )
>
> attachment is a zip file with changed extension ( gmail checks for py
> files .... ) and contains only changed files (pypy 5.7.1)
>
> Now I will try older compilers to see if I could catch my initial crash
> with python project, but in a few weeks time.
> Still think, that it is ok to share changes - someone could try and see
> what is needed for future support of vs2015/vs2017
>
> Best regards
> Sergey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170405/4d0cf8c9/attachment.html>

From sergey.forum at gmail.com  Wed Apr  5 10:56:26 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 5 Apr 2017 17:56:26 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
Message-ID: <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>

Hi,

with  additionally changed pypy\rpython\rlib\_rsocket_rffi.py file
(see attachment)
pypy  now compiles with  vs2015 and work on simple tests ( see
previous explanations after this mail text )

( one more note - I had to change expat to compile to dll - static lib
won't pass test when compiled with python.exe
and  while pypy would pass this step it would later report memory
errors ( I even tried setting allocations from  higher addresses (as
using MEM_TOP_DOWN in VirtualAlloc via registry setting
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session
Manager\Memory Management\AllocationPreference  to 0x100000 )
) even with jit disabled and memory block set  PYPY_GC_MAX_DELTA=200MB
--jit loop_longevity=300 )

now I have an opportunity to track my project problems.

Regards
Sergey

On Wed, Apr 5, 2017 at 3:58 PM, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
>
> Hi,
>
> btw seems I got why error 10035 appears in VS 2015 build network calls,
>
> in pypy code there is check for EWOULDBLOCK and required steps are made
> to deal with situation.
>
> but in VS 2015 EWOULDBLOCK is defined as
>
> #define EWOULDBLOCK     140
>
> while 10035 error is defined as
>
> #define WSAEWOULDBLOCK                   10035L
>
> so all code logic  checking real EWOULDBLOCK is misused by pypy compiled
> with VS 2015
>
> now will try to play  with that new definition, possibly code will start to
> make socket calls in VS 2015.
>
> Regards
> Sergey
>
>
> On Tue, Apr 4, 2017 at 8:43 AM, Sergey Kurdakov <sergey.forum at gmail.com>
> wrote:
>>
>> Hi,
>>
>> for anyone interested here are my changes to compile with VS2015 compiler
>> in attachment (over pypy version  5.7.1)
>>
>> I compiled with stock python
>>
>> cd pypy/goal
>> python  ../../rpython/bin/rpython --opt=jit
>>
>> compilation options in files are changed manually to reflect new compiler
>>
>> rpython\translator\platform\windows.py
>>
>> in _get_msvc_env(vsver, x64flag)
>> toolsdir = os.environ['VS140COMNTOOLS']
>>
>> vcvars = "C:\\Program Files (x86)\\Microsoft Visual Studio
>> 14.0\\Common7\\Tools\\vsvars32.bat"#os.path.join(toolsdir, 'vsvars32.bat')
>>
>> otherwise - I followed http://doc.pypy.org/en/latest/windows.html
>>
>> few caveats:
>> VS2015 now loads ucrtbase.dll in place of msvcrt.dll
>>
>> changed _PyVerify_fd implementation as it won't compile,
>> fixed few other compilation issues.
>>
>> the compilation works, but all network calls end with
>> [Errno 10035] A non-blocking socket operation could not be completed
>> immediately ( but _PyVerify_fd works correctly )
>>
>> did not figure  out so far why  it happens.
>>
>> while changes are not production ready - they could be a hint what might
>> be needed to change in pypy to compile with new
>> ms compilers ( ucrtbase vs msvcrt etc, new _PyVerify_fd etc )
>>
>> attachment is a zip file with changed extension ( gmail checks for py
>> files .... ) and contains only changed files (pypy 5.7.1)
>>
>> Now I will try older compilers to see if I could catch my initial crash
>> with python project, but in a few weeks time.
>> Still think, that it is ok to share changes - someone could try and see
>> what is needed for future support of vs2015/vs2017
>>
>> Best regards
>> Sergey
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy571_msvc14_changes.zip
Type: application/zip
Size: 109385 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170405/54382591/attachment-0001.zip>

From armin.rigo at gmail.com  Wed Apr  5 15:08:02 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Wed, 5 Apr 2017 21:08:02 +0200
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
Message-ID: <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>

Hi Sergey,

On 5 April 2017 at 16:56, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
> with  additionally changed pypy\rpython\rlib\_rsocket_rffi.py file
> (see attachment)

Cool!  But it would be more useful for us if you could open a pull
request on the bitbucket project page, https://bitbucket.org/pypy/pypy
.  Failing that, I could attempt to turn your attached files into a
pull request.


A bient?t,

Armin.

From sergey.forum at gmail.com  Wed Apr  5 15:54:13 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 5 Apr 2017 22:54:13 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
Message-ID: <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>

Hi Armin,

ok, I will prepare pull request,

though there are other things to change.

somehow openssl crashes on callback

openssl is compiled by default with __cdecl, but export win32
functions in pypy are defined as __stdcall so callback to openssl is
sent as stdcall but it expects __cdecl ( maybe I could just change
that callback declaration to __cdecl)
but maybe I just miss something, but I will look into issue, and when
I'm fine with it I  will make pull request then.

Regards
Sergey

On Wed, Apr 5, 2017 at 10:08 PM, Armin Rigo <armin.rigo at gmail.com> wrote:
> Hi Sergey,
>
> On 5 April 2017 at 16:56, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
>> with  additionally changed pypy\rpython\rlib\_rsocket_rffi.py file
>> (see attachment)
>
> Cool!  But it would be more useful for us if you could open a pull
> request on the bitbucket project page, https://bitbucket.org/pypy/pypy
> .  Failing that, I could attempt to turn your attached files into a
> pull request.
>
>
> A bient?t,
>
> Armin.

From matti.picus at gmail.com  Wed Apr  5 16:04:30 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 5 Apr 2017 23:04:30 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
Message-ID: <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>

On 05/04/17 22:54, Sergey Kurdakov wrote:

> Hi Armin,
>
> ok, I will prepare pull request,
>
> though there are other things to change.
>
> somehow openssl crashes on callback
>
> openssl is compiled by default with __cdecl, but export win32
> functions in pypy are defined as __stdcall so callback to openssl is
> sent as stdcall but it expects __cdecl ( maybe I could just change
> that callback declaration to __cdecl)
> but maybe I just miss something, but I will look into issue, and when
> I'm fine with it I  will make pull request then.
>
> Regards
> Sergey

How are you coping with third party packages?
Were these directions at all useful 
http://pypy.readthedocs.io/en/latest/windows.html#nonabrided-method-building-from-scratch
or are you using the cpython build scripts with your compiler?
Matti

From sergey.forum at gmail.com  Wed Apr  5 16:15:27 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Wed, 5 Apr 2017 23:15:27 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
Message-ID: <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>

Hi Matti,

>How are you coping with third party packages?

I built them myself,

>Were these directions at all useful

they were useful to the extent, for example openssl won't build with
these instructions ( nasm step was missing ) also opensssl will use
/MT library option by default after ms/do_ms.bat call, but all libs
are recommended to be built with /MD so I changed flag in generated
mak file.

>or are you using the cpython build scripts with your compiler

no just build them as recommended by each library (and t setting /MD
etc for consistensy)

Regards
Sergey

On Wed, Apr 5, 2017 at 11:04 PM, Matti Picus <matti.picus at gmail.com> wrote:
> On 05/04/17 22:54, Sergey Kurdakov wrote:
>
>> Hi Armin,
>>
>> ok, I will prepare pull request,
>>
>> though there are other things to change.
>>
>> somehow openssl crashes on callback
>>
>> openssl is compiled by default with __cdecl, but export win32
>> functions in pypy are defined as __stdcall so callback to openssl is
>> sent as stdcall but it expects __cdecl ( maybe I could just change
>> that callback declaration to __cdecl)
>> but maybe I just miss something, but I will look into issue, and when
>> I'm fine with it I  will make pull request then.
>>
>> Regards
>> Sergey
>
>
> How are you coping with third party packages?
> Were these directions at all useful
> http://pypy.readthedocs.io/en/latest/windows.html#nonabrided-method-building-from-scratch
> or are you using the cpython build scripts with your compiler?
> Matti
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From victor.stinner at gmail.com  Wed Apr  5 16:32:20 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 5 Apr 2017 22:32:20 +0200
Subject: [pypy-dev] performance benchmark suite
Message-ID: <CAMpsgwbiuuco8DQ+cpeAxa5UcU3R_96pbtD=GWs+G8O3vhVuXA@mail.gmail.com>

Hi,

I'm working on speed.python.org, CPython benchmark. I reworked the
benchmark suite which is now called "performance":

   http://pyperformance.readthedocs.io/

performance contains 54 benchmarks and works on Python 2.7 and 3.x. It
creates a virtual environment with pinned versions of requirements to
"isolate" the benchmark from the system, to  get more reproductible
results. I added a few benchmarks from the PyPy benchmark suite but I
didn't add all of them yet.

performance is now based on my perf module. The perf module is a
toolkit to run, analyze and compare benchmarks:

   http://perf.readthedocs.io/

I would like to know how to adapt perf and performance to handle
correctly PyPy JIT compiler: I would like to measure the performance
when code has been optimized by the JIT compiler and ignore the warmup
phase. I already made a few changes in perf and performance when a JIT
is detected, but I'm not sure that I did them correctly.

My final goal would be to have PyPy benchmark results on
speed.python.org, to easily compare CPython and PyPy (using the same
benchmark runner, same physical server).

The perf module calibrates a benchmark based on time: it computes the
number of outer loops to get a timing of at least 100 ms. Basically, a
single value is computed as:

  t0 = perf.perf_counter()
  for _ in range(loops): func()
  value = perf.perf_counter() - t0

perf spawn a process only to calibrate the benchmark. On PyPy, it now
(in the master branch) spawns a second process only computing warmup
samples to validate the calibration. If a value becomes less than 100
ms, it doubles each time the number of loops. The opereation is
repeated until the number of loops doesn't change.

After the calibration, perf spawns worker processes sequentially: each
worker computes warmup samples and then compute values.

By default, each worker computes 1 warmup sample and 3 samples on
CPython, and 10 warmup samples an 10 samples on PyPy.

The configuration for PyPy is kind of arbitrary, wheras it was finely
tuned for CPython.

At the end, perf ignores all warmup samples and only computes the mean
and standard deviations of other values. For example, on CPython 21
processes are spawned: 1 calibration + 20 workers, each worker
computes 1 warmup + 3 values: compute the mean of 60 values.

perf stores all data in a JSON file: metadata (hostname, CPU speed,
system load, etc.), number of loops, warmup samples, samples, etc. It
provides an API to access all data.

perf also contains a lot of tools to analyze data: statistics (min,
max, median/MAD, percentiles, ...), render an histogram, compare
results and check if the difference is significant, detect unstable
benchmark, etc.

perf also contains a documentation explaining how to: run benchmark,
analyze benchmarks, get stable/reproductible results, tune your system
to run a benchmark, etc.

To tune your system for benchmarks, run the "sudo python3 -m perf
system tune" command. It configures the CPU (disable Turbo Boost, set
a fixed frequency, ...), check that the power cable is plugged, set
CPU affinity on IRQs, disable Linux perf events, etc. The command
reduces the operating system jitter.

Victor

From victor.stinner at gmail.com  Thu Apr  6 05:43:43 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 6 Apr 2017 11:43:43 +0200
Subject: [pypy-dev] performance benchmark suite
In-Reply-To: <CAMpsgwbiuuco8DQ+cpeAxa5UcU3R_96pbtD=GWs+G8O3vhVuXA@mail.gmail.com>
References: <CAMpsgwbiuuco8DQ+cpeAxa5UcU3R_96pbtD=GWs+G8O3vhVuXA@mail.gmail.com>
Message-ID: <CAMpsgwZr=oTM6KnnyQPUGdWRBXuS1H-kZU+enjFjy28iTrVomw@mail.gmail.com>

Ok, let's be more concrete: I ran benchmarks with PyPy2 v5.7.1 on the
speed-python server. See attached pypy.json.gz file.

"perf check pypy.json.gz" detected the 10 benchmarks as "unstable".

Let's use pathlib as an example (Mean +- std dev: 28.2 ms +- 5.4 ms).
If you look closer, I confirm that performance is unstable. It seems
like the distribution is multi-modal with 3 ranges around: 21.7 ms,
27.4 ms and  33.1 ms. It's very hard to summarize such distribution
with a single mean or even median value.

I should now check if pathlib becomes more stable if it runs longer.

perf 1.0 now displays results using mean and standard deviation. See
perf doc for the rationale:
http://perf.readthedocs.io/en/latest/analyze.html#statistics


logging_silent
--------------

WARNING: the benchmark result may be unstable
* the shortest raw value is only 9.78 us

pathlib
-------

WARNING: the benchmark result may be unstable
* the standard deviation (5.42 ms) is 19% of the mean (28.2 ms)

regex_compile
-------------

WARNING: the benchmark result may be unstable
* the standard deviation (14.0 ms) is 12% of the mean (120 ms)

scimark_sparse_mat_mult
-----------------------

WARNING: the benchmark result may be unstable
* the standard deviation (19.9 us) is 11% of the mean (188 us)

spambayes
---------

WARNING: the benchmark result may be unstable
* the standard deviation (16.4 ms) is 19% of the mean (85.2 ms)
* the maximum (133 ms) is 56% greater than the mean (85.2 ms)

sqlalchemy_imperative
---------------------

WARNING: the benchmark result may be unstable
* the standard deviation (51.5 ms) is 39% of the mean (134 ms)
* the minimum (42.7 ms) is 68% smaller than the mean (134 ms)
* the maximum (267 ms) is 100% greater than the mean (134 ms)

sympy_integrate
---------------

WARNING: the benchmark result may be unstable
* the standard deviation (21.6 ms) is 14% of the mean (150 ms)

sympy_sum
---------

WARNING: the benchmark result may be unstable
* the standard deviation (19.5 ms) is 13% of the mean (151 ms)

sympy_str
---------

WARNING: the benchmark result may be unstable
* the standard deviation (23.4 ms) is 13% of the mean (174 ms)

xml_etree_process
-----------------

WARNING: the benchmark result may be unstable
* the standard deviation (7.64 ms) is 12% of the mean (62.9 ms)


haypo at selma$ python3 -m perf stats pypy.json.gz -b pathlib -q
Total duration: 32.8 sec
Start date: 2017-04-05 21:16:25
End date: 2017-04-05 21:17:08
Raw value minimum: 169 ms
Raw value maximum: 284 ms

Number of runs: 9
Total number of values: 60
Number of values per run: 10
Number of warmups per run: 10
Loop iterations per value: 8

Minimum:         21.2 ms
Median +- MAD:   29.9 ms +- 4.0 ms
Mean +- std dev: 28.2 ms +- 5.4 ms
Maximum:         35.4 ms

  0th percentile: 21.2 ms (-25% of the mean) -- minimum
  5th percentile: 21.4 ms (-24% of the mean)
 25th percentile: 22.2 ms (-21% of the mean)
 50th percentile: 29.9 ms (+6% of the mean) -- median
 75th percentile: 33.3 ms (+18% of the mean)
 95th percentile: 34.1 ms (+21% of the mean)
100th percentile: 35.4 ms (+26% of the mean) -- maximum


haypo at selma$ python3 -m perf hist pypy.json.gz -b pathlib -q
21.1 ms:  7 ###########################
21.7 ms: 12 ###############################################
22.3 ms:  2 ########
22.8 ms:  3 ############
23.4 ms:  0 |
24.0 ms:  0 |
24.5 ms:  0 |
25.1 ms:  0 |
25.7 ms:  0 |
26.3 ms:  1 ####
26.8 ms:  1 ####
27.4 ms:  4 ################
28.0 ms:  0 |
28.5 ms:  0 |
29.1 ms:  0 |
29.7 ms:  0 |
30.2 ms:  0 |
30.8 ms:  0 |
31.4 ms:  1 ####
32.0 ms:  4 ################
32.5 ms:  5 ####################
33.1 ms: 13 ###################################################
33.7 ms:  5 ####################
34.2 ms:  1 ####
34.8 ms:  0 |
35.4 ms:  1 ####


$ python3 -m perf dump pypy.json.gz -b pathlib -q
Run 4: values (10): 33.1 ms (+17%), 21.8 ms (-23%), 33.5 ms (+19%),
22.2 ms (-21%), 33.5 ms (+19%), 27.8 ms, 22.9 ms (-19%), 32.4 ms
(+15%), 21.4 ms (-24%), 33.1 ms (+17%)
Run 5: values (10): 33.1 ms (+17%), 21.7 ms (-23%), 33.4 ms (+18%),
22.2 ms (-21%), 33.5 ms (+19%), 27.8 ms, 22.7 ms (-20%), 32.2 ms
(+14%), 21.3 ms (-24%), 33.3 ms (+18%)
Run 6: values (10): 33.0 ms (+17%), 21.8 ms (-23%), 33.5 ms (+19%),
22.2 ms (-21%), 33.9 ms (+20%), 27.4 ms, 32.0 ms (+13%), 23.0 ms
(-19%), 21.3 ms (-25%), 34.1 ms (+21%)
Run 7: values (10): 32.9 ms (+17%), 21.8 ms (-23%), 33.4 ms (+18%),
22.2 ms (-21%), 34.0 ms (+20%), 27.5 ms, 32.0 ms (+13%), 22.9 ms
(-19%), 21.5 ms (-24%), 34.0 ms (+21%)
Run 8: values (10): 33.0 ms (+17%), 21.9 ms (-22%), 34.2 ms (+21%),
22.2 ms (-21%), 35.4 ms (+26%), 26.7 ms (-5%), 33.1 ms (+17%), 22.2 ms
(-21%), 21.5 ms (-24%), 34.6 ms (+23%)
Run 9: values (10): 33.1 ms (+17%), 21.7 ms (-23%), 33.3 ms (+18%),
22.0 ms (-22%), 33.5 ms (+19%), 27.8 ms, 22.6 ms (-20%), 32.3 ms
(+15%), 21.2 ms (-25%), 33.2 ms (+18%)


haypo at selma$ python3 -m perf dump pypy.json.gz -b pathlib
Run 1: calibrate
- 1 loop: 135 ms (raw: 135 ms)
Run 2: calibrate
- 1 loop: 136 ms (raw: 136 ms)
- 1 loop: 32.2 ms (raw: 32.2 ms)
- 2 loops: 48.2 ms (raw: 96.5 ms)
- 4 loops: 22.6 ms (raw: 90.4 ms)
- 8 loops: 26.8 ms (raw: 214 ms)
- 8 loops: 22.7 ms (raw: 181 ms)
- 8 loops: 29.4 ms (raw: 235 ms)
- 8 loops: 22.7 ms (raw: 182 ms)
- 8 loops: 34.0 ms (raw: 272 ms)
- 8 loops: 22.4 ms (raw: 179 ms)
- 8 loops: 21.7 ms (raw: 174 ms)
- 8 loops: 33.1 ms (raw: 265 ms)
- 8 loops: 21.9 ms (raw: 175 ms)
Run 3: calibrate
- 8 loops: 42.9 ms (raw: 343 ms)
- 8 loops: 26.9 ms (raw: 215 ms)
- 8 loops: 22.3 ms (raw: 179 ms)
- 8 loops: 29.3 ms (raw: 235 ms)
- 8 loops: 22.9 ms (raw: 183 ms)
- 8 loops: 31.2 ms (raw: 250 ms)
- 8 loops: 23.9 ms (raw: 191 ms)
- 8 loops: 21.8 ms (raw: 174 ms)
- 8 loops: 32.5 ms (raw: 260 ms)
- 8 loops: 21.8 ms (raw: 174 ms)
Run 4: warmups (10): 42.3 ms (+50%), 26.8 ms, 22.2 ms (-21%), 29.4 ms,
22.5 ms (-20%), 30.8 ms (+9%), 23.8 ms (-16%), 21.8 ms (-23%), 32.4 ms
(+15%), 21.7 ms (-23%); values (10): 33.1 ms (+17%), 21.8 ms (-23%),
33.5 ms (+19%), 22.2 ms (-21%), 33.5 ms (+19%), 27.8 ms, 22.9 ms
(-19%), 32.4 ms (+15%), 21.4 ms (-24%), 33.1 ms (+17%)
Run 5: warmups (10): 42.2 ms (+50%), 26.9 ms, 22.6 ms (-20%), 29.6 ms,
22.7 ms (-19%), 31.3 ms (+11%), 23.7 ms (-16%), 22.2 ms (-21%), 32.6
ms (+16%), 21.7 ms (-23%); values (10): 33.1 ms (+17%), 21.7 ms
(-23%), 33.4 ms (+18%), 22.2 ms (-21%), 33.5 ms (+19%), 27.8 ms, 22.7
ms (-20%), 32.2 ms (+14%), 21.3 ms (-24%), 33.3 ms (+18%)
Run 6: warmups (10): 42.3 ms (+50%), 26.8 ms (-5%), 22.2 ms (-21%),
29.2 ms, 22.3 ms (-21%), 30.6 ms (+8%), 23.9 ms (-15%), 21.6 ms
(-24%), 32.5 ms (+15%), 21.5 ms (-24%); values (10): 33.0 ms (+17%),
21.8 ms (-23%), 33.5 ms (+19%), 22.2 ms (-21%), 33.9 ms (+20%), 27.4
ms, 32.0 ms (+13%), 23.0 ms (-19%), 21.3 ms (-25%), 34.1 ms (+21%)
Run 7: warmups (10): 42.5 ms (+51%), 26.8 ms, 22.2 ms (-21%), 29.3 ms,
22.7 ms (-19%), 31.1 ms (+10%), 23.8 ms (-16%), 21.7 ms (-23%), 32.3
ms (+15%), 21.6 ms (-23%); values (10): 32.9 ms (+17%), 21.8 ms
(-23%), 33.4 ms (+18%), 22.2 ms (-21%), 34.0 ms (+20%), 27.5 ms, 32.0
ms (+13%), 22.9 ms (-19%), 21.5 ms (-24%), 34.0 ms (+21%)
Run 8: warmups (10): 43.4 ms (+54%), 26.9 ms, 22.5 ms (-20%), 29.8 ms
(+5%), 22.9 ms (-19%), 33.4 ms (+19%), 23.2 ms (-18%), 22.0 ms (-22%),
32.2 ms (+14%), 21.8 ms (-23%); values (10): 33.0 ms (+17%), 21.9 ms
(-22%), 34.2 ms (+21%), 22.2 ms (-21%), 35.4 ms (+26%), 26.7 ms (-5%),
33.1 ms (+17%), 22.2 ms (-21%), 21.5 ms (-24%), 34.6 ms (+23%)
Run 9: warmups (10): 42.2 ms (+50%), 27.3 ms, 22.6 ms (-20%), 29.4 ms,
22.3 ms (-21%), 30.8 ms (+9%), 23.7 ms (-16%), 21.4 ms (-24%), 32.9 ms
(+16%), 21.8 ms (-23%); values (10): 33.1 ms (+17%), 21.7 ms (-23%),
33.3 ms (+18%), 22.0 ms (-22%), 33.5 ms (+19%), 27.8 ms, 22.6 ms
(-20%), 32.3 ms (+15%), 21.2 ms (-25%), 33.2 ms (+18%)

WARNING: the benchmark result may be unstable
* the standard deviation (5.42 ms) is 19% of the mean (28.2 ms)

Try to rerun the benchmark with more runs, values and/or loops.
Run 'python3 -m perf system tune' command to reduce the system jitter.
Use perf stats, perf dump and perf hist to analyze results.
Use --quiet option to hide these warnings.

Victor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy.json.gz
Type: application/x-gzip
Size: 110568 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170406/b54872bb/attachment-0001.bin>

From sergey.forum at gmail.com  Thu Apr  6 08:40:57 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Thu, 6 Apr 2017 15:40:57 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
 <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
Message-ID: <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>

Hi Armin,

concerning pull request.

there are few issues:

the new PyVerify_fd  code will not work with vs 2013 as that compiler
has a bug: it reports console fd s as positive numbers ( earlier ms
compilers and vs 2015 are correct to return negative values )
so both versions ( previous and new one ) of the code ( now lacking in
my changes - only new code ) had to be included
will add it to my changes.

the other new C code also would be ifdef ed for the same reasons.

So I will include older code to pypy code - but ifdef ed.

there is another issue with current changes

cfunc = get_on_lib(ctypes.cdll.ucrtbase, funcname) in addition to
cfunc = get_on_lib(ctypes.cdll.msvcrt, funcname)

in /rpython/rtyper/lltypesystem/ll2ctypes.py

in previews versions of compiler there was no ucrtbase, so some checks
will be needed ( so far I have no idea how to make it better )


as for my last error I observed.

also to Matti

interestingly, debug build of pypy does not exhibit the  problem  with
openssl and the only difference between builds  I could observe so far
- is that debug allocates more stack

/rpython/translator/platform/windows.py

stack_size = 8 << 20  # 8 Mb

self.link_flags = self.link_flags + ('/STACK:%d' % stack_size,)

( so that function call fail which I reported in this  thread might be
not calling convention fail  but lack of enough stack memory might be
a culprit ) , thus I will try to play with this in release build

as I do this research is spare time.
I hope that I will appear with code in a week time.

Best regards
Sergey

From phyo.arkarlwin at gmail.com  Fri Apr  7 05:08:28 2017
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Fri, 07 Apr 2017 09:08:28 +0000
Subject: [pypy-dev] 2,
 7 and 3.5 release is almost here - please help check you favorite
 platform
In-Reply-To: <965ee337-3068-0066-225b-0d806abed7ed@gmail.com>
References: <77d8e605-f9fc-3bf4-5491-fece4eb76863@gmail.com>
 <CA+HjJriBiO225HkeLWNHrJh8T_90P_7-3D81fEgyiP181E3dTg@mail.gmail.com>
 <CAMSv6X1AZt67Uh_ONN1UKn2feT=RHc9TjEvQ8=3zG4evPEXyHA@mail.gmail.com>
 <965ee337-3068-0066-225b-0d806abed7ed@gmail.com>
Message-ID: <CA+HjJrh7otTS97Vq4ETroZoRtJfs=yK9ufgUvjb0i5pA44vz1g@mail.gmail.com>

I am so excited to jump to 3.5x , thanks a lot guys.
Any significant difference compare to 2.7x or features not passing tests ?

On Fri, Mar 24, 2017 at 12:25 AM Matti Picus <matti.picus at gmail.com> wrote:

> On 23/03/17 12:46, Armin Rigo wrote:
>
> > Hi Phyo,
> >
> > On 21 March 2017 at 05:53, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> >> Teating. Saw warning that it is much slower than pypy2? How much slower?
> > This warning should be removed or at least made much less strong.  We
> > didn't measure, but it passes many of the same tests for JIT-code
> > quality now.  Where did we leave such a warning?
> >
> >
> > A bient?t,
> >
> > Armin.
> It's in the release notice/blog post. Sorry, a bit late to refine that
> now :(
> Matti
> _______________________________________________
> 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/20170407/848930da/attachment.html>

From phyo.arkarlwin at gmail.com  Fri Apr  7 05:09:00 2017
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Fri, 07 Apr 2017 09:09:00 +0000
Subject: [pypy-dev] 2,
 7 and 3.5 release is almost here - please help check you favorite
 platform
In-Reply-To: <CA+HjJrh7otTS97Vq4ETroZoRtJfs=yK9ufgUvjb0i5pA44vz1g@mail.gmail.com>
References: <77d8e605-f9fc-3bf4-5491-fece4eb76863@gmail.com>
 <CA+HjJriBiO225HkeLWNHrJh8T_90P_7-3D81fEgyiP181E3dTg@mail.gmail.com>
 <CAMSv6X1AZt67Uh_ONN1UKn2feT=RHc9TjEvQ8=3zG4evPEXyHA@mail.gmail.com>
 <965ee337-3068-0066-225b-0d806abed7ed@gmail.com>
 <CA+HjJrh7otTS97Vq4ETroZoRtJfs=yK9ufgUvjb0i5pA44vz1g@mail.gmail.com>
Message-ID: <CA+HjJrjmvBAXGCoOLy_riLd78THAnvo2-mV-qLZR=9K0XAZxSg@mail.gmail.com>

I want to mean if there any Significant performance difference between Pypy
2.7x and 3.5x

On Fri, Apr 7, 2017 at 3:38 PM Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:

> I am so excited to jump to 3.5x , thanks a lot guys.
> Any significant difference compare to 2.7x or features not passing tests ?
>
> On Fri, Mar 24, 2017 at 12:25 AM Matti Picus <matti.picus at gmail.com>
> wrote:
>
> On 23/03/17 12:46, Armin Rigo wrote:
>
> > Hi Phyo,
> >
> > On 21 March 2017 at 05:53, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> >> Teating. Saw warning that it is much slower than pypy2? How much slower?
> > This warning should be removed or at least made much less strong.  We
> > didn't measure, but it passes many of the same tests for JIT-code
> > quality now.  Where did we leave such a warning?
> >
> >
> > A bient?t,
> >
> > Armin.
> It's in the release notice/blog post. Sorry, a bit late to refine that
> now :(
> Matti
> _______________________________________________
> 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/20170407/0629673f/attachment.html>

From armin.rigo at gmail.com  Fri Apr  7 06:13:08 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Fri, 7 Apr 2017 12:13:08 +0200
Subject: [pypy-dev] 2,
 7 and 3.5 release is almost here - please help check you favorite
 platform
In-Reply-To: <CA+HjJrjmvBAXGCoOLy_riLd78THAnvo2-mV-qLZR=9K0XAZxSg@mail.gmail.com>
References: <77d8e605-f9fc-3bf4-5491-fece4eb76863@gmail.com>
 <CA+HjJriBiO225HkeLWNHrJh8T_90P_7-3D81fEgyiP181E3dTg@mail.gmail.com>
 <CAMSv6X1AZt67Uh_ONN1UKn2feT=RHc9TjEvQ8=3zG4evPEXyHA@mail.gmail.com>
 <965ee337-3068-0066-225b-0d806abed7ed@gmail.com>
 <CA+HjJrh7otTS97Vq4ETroZoRtJfs=yK9ufgUvjb0i5pA44vz1g@mail.gmail.com>
 <CA+HjJrjmvBAXGCoOLy_riLd78THAnvo2-mV-qLZR=9K0XAZxSg@mail.gmail.com>
Message-ID: <CAMSv6X0Ta5sR7mGTOyEUvBVQ+ECnvj0LOwFuGhJ8AeYVnSVNAQ@mail.gmail.com>

Hi Phyo,

On 7 April 2017 at 11:09, Phyo Arkar <phyo.arkarlwin at gmail.com> wrote:
> I want to mean if there any Significant performance difference between Pypy
> 2.7x and 3.5x

You tell us.  We don't have automatic benchmark runners for PyPy3.5.
Our knowledge so far is limited to the test_pypy_c tests, which are
not completely fixed but show that the JIT emits reasonable code at
least in the common cases.


A bient?t,

Armin.

From armin.rigo at gmail.com  Fri Apr  7 06:25:57 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Fri, 7 Apr 2017 12:25:57 +0200
Subject: [pypy-dev] performance benchmark suite
In-Reply-To: <CAMpsgwZr=oTM6KnnyQPUGdWRBXuS1H-kZU+enjFjy28iTrVomw@mail.gmail.com>
References: <CAMpsgwbiuuco8DQ+cpeAxa5UcU3R_96pbtD=GWs+G8O3vhVuXA@mail.gmail.com>
 <CAMpsgwZr=oTM6KnnyQPUGdWRBXuS1H-kZU+enjFjy28iTrVomw@mail.gmail.com>
Message-ID: <CAMSv6X3g6PSs+fNxYx1vYOs8Tv19sT4fuhOgK6b8mk=M-E8NEA@mail.gmail.com>

Hi Victor,

On 6 April 2017 at 11:43, Victor Stinner <victor.stinner at gmail.com> wrote:
> Ok, let's be more concrete: I ran benchmarks with PyPy2 v5.7.1 on the
> speed-python server. See attached pypy.json.gz file.

Note that unless your mails contain precise questions, you're unlikely
to get much answers, because we don't know about what you need
feedback.

In this case, I have a strong hint about that:

> If you look closer, I confirm that performance is unstable. It seems
> like the distribution is multi-modal with 3 ranges around: 21.7 ms,
> 27.4 ms and  33.1 ms.

These numbers are too short to be precisely relevant.  A major garbage
collection occurs more rarely than that.  So my guess is something
like: you get 33ms when a major GC occurs and 21ms when it does not.
Moreover, our GC is incremental, so a single major GC occurs over some
non-null period of progress---possibly partly in one run and partly in
the next one.  (There are also minor GCs but these ones should occur
every few millisecond.)


A bient?t,

Armin.

From sergey.forum at gmail.com  Sat Apr  8 12:26:32 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Sat, 8 Apr 2017 19:26:32 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
 <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
 <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>
Message-ID: <CAFVQEu3ujCytTi6iZJZoKfyJOHwh9j_oMWsNbmexuM9b_7ARoQ@mail.gmail.com>

Hi Armin and Matti,

now my project works.

So concerning current stock installation of pypy seems that the only
problem was a lack of sufficient stack space on windows,
in debug pypy  is configured to increase stack, but in release it is
not. And as stack space is insufficient - some code might crash on
windows (on linux stack is by default is bigger - so no problem occurs
 ).

while I'm preparing my changes, is it possible, that current code is
changed that pypy on windows is compiled in release build with
increased stack, possibly even some more, than currently in debug
mode?

another point.

while compiling pypy lack of memory is an issue even on machines with
more memory that required for compilation.

Basically pypy  will crash when achieves 2 Gb memory limit even with
setting pypy to use extended memory
I  suppose it starts to interfere with system memory addresses which
are located exactly at 2 Gb starting point,

but VirtualAlloc allows explicitly to allocate memory from higher
addresses and avoid system memory clashes when memory is continuously
allocated.

Here - one change would be  required ( which I would not attempt now
as have insufficient knowledge of pypy internals )
to use not a stock malloc, but a redefined (wrapper) malloc which will
call to windows VirtualAlloc with appropriate MEM_TOP_DOWN flag.  The
flag could be passed to pypy in command line to indicate, that memory
should be allocated from top. Then on machines which have enough
memory ( I have 8 Gb - but pypy will still report memory error when
compiling itself ) there will not be memory problems.

Best regards
Sergey

From matti.picus at gmail.com  Sat Apr  8 14:53:05 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Sat, 8 Apr 2017 21:53:05 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu3ujCytTi6iZJZoKfyJOHwh9j_oMWsNbmexuM9b_7ARoQ@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
 <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
 <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>
 <CAFVQEu3ujCytTi6iZJZoKfyJOHwh9j_oMWsNbmexuM9b_7ARoQ@mail.gmail.com>
Message-ID: <c7fbee2b-32c5-2811-727b-828f2733c0ce@gmail.com>

On 08/04/17 19:26, Sergey Kurdakov wrote:

> while compiling pypy lack of memory is an issue even on machines with
> more memory that required for compilation.
>
> Basically pypy  will crash when achieves 2 Gb memory limit even with
> setting pypy to use extended memory
> I  suppose it starts to interfere with system memory addresses which
> are located exactly at 2 Gb starting point,
Are you using 64-bit windows? Then using the editbin /largeaddressaware 
trick as mentioned on the windows build page you should be able to 
access all your memory from the 32-bit python executable used for 
translation.
Matti

From sergey.forum at gmail.com  Sat Apr  8 15:36:11 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Sat, 8 Apr 2017 22:36:11 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <c7fbee2b-32c5-2811-727b-828f2733c0ce@gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
 <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
 <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>
 <CAFVQEu3ujCytTi6iZJZoKfyJOHwh9j_oMWsNbmexuM9b_7ARoQ@mail.gmail.com>
 <c7fbee2b-32c5-2811-727b-828f2733c0ce@gmail.com>
Message-ID: <CAFVQEu2aQEi-ez-ygNai2ZW7CSrM7=KWskDb8vGX2to_NxF0AA@mail.gmail.com>

Hi Matti,

>Are you using 64-bit windows? Then using the editbin /largeaddressaware trick as mentioned on the windows build >page you should be able to access all your memory from the 32-bit python executable used for translation.

yes I'm on windows 64 ( win 10/64 ) and  I did, but to no avail ( btw
pypy builds with largeaddressaware flag too - so it is there either
way )
so the memory error appears in spite of having /largeaddressaware trick,

Regards
Sergey


On Sat, Apr 8, 2017 at 9:53 PM, Matti Picus <matti.picus at gmail.com> wrote:
> On 08/04/17 19:26, Sergey Kurdakov wrote:
>
>> while compiling pypy lack of memory is an issue even on machines with
>> more memory that required for compilation.
>>
>> Basically pypy  will crash when achieves 2 Gb memory limit even with
>> setting pypy to use extended memory
>> I  suppose it starts to interfere with system memory addresses which
>> are located exactly at 2 Gb starting point,
>
> Are you using 64-bit windows? Then using the editbin /largeaddressaware
> trick as mentioned on the windows build page you should be able to access
> all your memory from the 32-bit python executable used for translation.
> Matti

From naylor.b.david at gmail.com  Sun Apr  9 06:00:13 2017
From: naylor.b.david at gmail.com (David Naylor)
Date: Sun, 09 Apr 2017 12:00:13 +0200
Subject: [pypy-dev] PyPy3.5 on FreeBSD
Message-ID: <2525258.t8F7PP6vc0@dragon.local>

Hi

A quick note: pypy3.5 is running on FreeBSD/amd64 (aka 64bit), at least well 
enough to compile the CFFI modules during packaging of pypy3.  

As noted in the release, pypy3 does not run from i386 (aka 32bit):

# /wrkdirs/usr/ports/lang/pypy3/work/pypy3-v5.7.1-src/pypy/goal/pypy3-c
'import site' failed
Python 3.5.3 (2875f328eae2216a87f3d6f335092832eb031f56, Apr 09 2017, 05:33:17)
[PyPy 5.7.1-beta0 with GCC 4.2.1 Compatible FreeBSD Clang 3.8.0 
(tags/RELEASE_380/final 262564)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``probably the last time in the
season, but: snow, snow!''
TypeError: 'NoneType' has no length

Regards

David (on behalf of the FreeBSD/Python team)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170409/b85b19b7/attachment.sig>

From cfbolz at gmx.de  Sun Apr  9 06:35:56 2017
From: cfbolz at gmx.de (Carl Friedrich Bolz-Tereick)
Date: Sun, 09 Apr 2017 12:35:56 +0200
Subject: [pypy-dev] PyPy3.5 on FreeBSD
In-Reply-To: <2525258.t8F7PP6vc0@dragon.local>
References: <2525258.t8F7PP6vc0@dragon.local>
Message-ID: <2661FA35-BE1A-4360-83C4-DBA0E75308DD@gmx.de>

Hi David, 

Cool! Note that pypy3 is not really working on any 32 bit platform so far. 

Would you be interested in having commit rights so you can fix the FreeBSD issues yourself? If yes, please mail me your bitbucket account privately. 

Cheers, 
Carl Friedrich

On April 9, 2017 12:00:13 PM GMT+02:00, David Naylor <naylor.b.david at gmail.com> wrote:
>Hi
>
>A quick note: pypy3.5 is running on FreeBSD/amd64 (aka 64bit), at least
>well 
>enough to compile the CFFI modules during packaging of pypy3.  
>
>As noted in the release, pypy3 does not run from i386 (aka 32bit):
>
># /wrkdirs/usr/ports/lang/pypy3/work/pypy3-v5.7.1-src/pypy/goal/pypy3-c
>'import site' failed
>Python 3.5.3 (2875f328eae2216a87f3d6f335092832eb031f56, Apr 09 2017,
>05:33:17)
>[PyPy 5.7.1-beta0 with GCC 4.2.1 Compatible FreeBSD Clang 3.8.0 
>(tags/RELEASE_380/final 262564)] on freebsd11
>Type "help", "copyright", "credits" or "license" for more information.
>And now for something completely different: ``probably the last time in
>the
>season, but: snow, snow!''
>TypeError: 'NoneType' has no length
>
>Regards
>
>David (on behalf of the FreeBSD/Python team)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170409/20e5956d/attachment-0001.html>

From armin.rigo at gmail.com  Mon Apr 10 04:10:22 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Mon, 10 Apr 2017 10:10:22 +0200
Subject: [pypy-dev] PyPy3.5 on FreeBSD
In-Reply-To: <2661FA35-BE1A-4360-83C4-DBA0E75308DD@gmx.de>
References: <2525258.t8F7PP6vc0@dragon.local>
 <2661FA35-BE1A-4360-83C4-DBA0E75308DD@gmx.de>
Message-ID: <CAMSv6X3QtvL7g3E5dQpNgNWpm3wEdhGDHbybpSjfO5dtDq_PeA@mail.gmail.com>

Hi,

On 9 April 2017 at 12:35, Carl Friedrich Bolz-Tereick <cfbolz at gmx.de> wrote:
> Cool! Note that pypy3 is not really working on any 32 bit platform so far.

On Linux, a 32-bit build is able to start, at least.  I have no idea
about the cryptic error message you're getting but it's probably a
platform-specific issue.


A bient?t,

Armin.

From sergey.forum at gmail.com  Mon Apr 10 13:45:48 2017
From: sergey.forum at gmail.com (Sergey Kurdakov)
Date: Mon, 10 Apr 2017 20:45:48 +0300
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu2aQEi-ez-ygNai2ZW7CSrM7=KWskDb8vGX2to_NxF0AA@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
 <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
 <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>
 <CAFVQEu3ujCytTi6iZJZoKfyJOHwh9j_oMWsNbmexuM9b_7ARoQ@mail.gmail.com>
 <c7fbee2b-32c5-2811-727b-828f2733c0ce@gmail.com>
 <CAFVQEu2aQEi-ez-ygNai2ZW7CSrM7=KWskDb8vGX2to_NxF0AA@mail.gmail.com>
Message-ID: <CAFVQEu3nPdF8+a=3SVnop93adF816wGMO-kuj1rZZgH=CUF3PQ@mail.gmail.com>

Hi Matti,

after double checking pypy-c.exe headers with

dumpbin /headers pypy-c.exe

(actually while objects are compiled with /LARGEADDRESSAWARE flag in
windows.py - final exe does not contain required flag so possibly here
- either this flag should be removed or set correctly such that
produced exe has needed headers as might be expected from setting
/LARGEADDRESSAWARE flag in code - will look into this in my merge
request)

and  running

editbin /LARGEADDRESSAWARE pypy-c.exe

I achieved compilation of pypy by pypy

but  I also set

BCDEDIT /Set IncreaseUserVa 3072

so my intent before pull request  is
a) to check  that /LARGEADDRESSAWARE flag in windows.py start to work
b) will check several times to be sure if BCDEDIT /Set IncreaseUserVa
3072 is really needed to work.

when I'm done will submit code and if it actually needed - also docs
to compile pypy on windows 64 could be changed such that it it does
not require additional efforts to investigate.

Regards
Sergey

On Sat, Apr 8, 2017 at 10:36 PM, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
> Hi Matti,
>
>>Are you using 64-bit windows? Then using the editbin /largeaddressaware trick as mentioned on the windows build >page you should be able to access all your memory from the 32-bit python executable used for translation.
>
> yes I'm on windows 64 ( win 10/64 ) and  I did, but to no avail ( btw
> pypy builds with largeaddressaware flag too - so it is there either
> way )
> so the memory error appears in spite of having /largeaddressaware trick,
>
> Regards
> Sergey
>
>
> On Sat, Apr 8, 2017 at 9:53 PM, Matti Picus <matti.picus at gmail.com> wrote:
>> On 08/04/17 19:26, Sergey Kurdakov wrote:
>>
>>> while compiling pypy lack of memory is an issue even on machines with
>>> more memory that required for compilation.
>>>
>>> Basically pypy  will crash when achieves 2 Gb memory limit even with
>>> setting pypy to use extended memory
>>> I  suppose it starts to interfere with system memory addresses which
>>> are located exactly at 2 Gb starting point,
>>
>> Are you using 64-bit windows? Then using the editbin /largeaddressaware
>> trick as mentioned on the windows build page you should be able to access
>> all your memory from the 32-bit python executable used for translation.
>> Matti

From armin.rigo at gmail.com  Tue Apr 11 03:06:19 2017
From: armin.rigo at gmail.com (Armin Rigo)
Date: Tue, 11 Apr 2017 09:06:19 +0200
Subject: [pypy-dev] Visual Studio 2015 build strange behavior
In-Reply-To: <CAFVQEu3nPdF8+a=3SVnop93adF816wGMO-kuj1rZZgH=CUF3PQ@mail.gmail.com>
References: <CAFVQEu3et-ui5PtCDCZna9e5Vf0FQDs=oC221ni_E7TTcdT3ZA@mail.gmail.com>
 <CAMSv6X2JWDwPcAEqauxok7ciRuBsKee9xkD7-kV3ppiXqTuZ5A@mail.gmail.com>
 <CAFVQEu2H=oKAdRXunQxsQ5Sg35KBvbVtgdAtxS2QqiVqbZS-qw@mail.gmail.com>
 <8A0B7A0B-6BBE-461E-A346-4638A9AC0C62@gmx.de>
 <CAFVQEu3DXVThn8RYQgVpM3ojO7zc7GnipoQcXgDaeBuBPvzxFA@mail.gmail.com>
 <CAFVQEu2rf32b6uGzvs0J_3OiRffv22qwNdUwnxNPJVq2ig04EA@mail.gmail.com>
 <CAFVQEu1xj=AtYW1JMG9F1i8C0qFHA88NuwV9XL9cxsZyftFwhw@mail.gmail.com>
 <CAMSv6X1A4sGuWNwB8eMSOvS5NWp1miVt7P_E3NXmAtY-SFwWRA@mail.gmail.com>
 <CAFVQEu2yt-WnSFofARUzPS6CCN95ZTCFNn7aC_s=OPxz=QnMfQ@mail.gmail.com>
 <39ed6143-70b7-876f-437f-a9f89928eb68@gmail.com>
 <CAFVQEu1Q_0zGuO4JCFiW6JMGASfoFOk3thHvqJb-Wub6j5GzsQ@mail.gmail.com>
 <CAFVQEu2NmLKMbmPLN9uGnUboaCpsS56fZF7VSz=nUQ2cTx3n5g@mail.gmail.com>
 <CAFVQEu3ujCytTi6iZJZoKfyJOHwh9j_oMWsNbmexuM9b_7ARoQ@mail.gmail.com>
 <c7fbee2b-32c5-2811-727b-828f2733c0ce@gmail.com>
 <CAFVQEu2aQEi-ez-ygNai2ZW7CSrM7=KWskDb8vGX2to_NxF0AA@mail.gmail.com>
 <CAFVQEu3nPdF8+a=3SVnop93adF816wGMO-kuj1rZZgH=CUF3PQ@mail.gmail.com>
Message-ID: <CAMSv6X1VNt4G_J_XHFyUDDbCppsQuY3+w5e6FzKDJ1LiSpwaDw@mail.gmail.com>

Hi Sergey,

On 10 April 2017 at 19:45, Sergey Kurdakov <sergey.forum at gmail.com> wrote:
> BCDEDIT /Set IncreaseUserVa 3072

According to the documentation here:
https://msdn.microsoft.com/en-us/library/windows/hardware/bb613473(v=vs.85).aspx
this line has no effect on Windows 64 (even if the running program is
32-bit), but is required on a 32-bit Windows in order to configure the
system in a way that after reboot(!) it will let all(!) its
applications use more than 2GB.


A bient?t,

Armin.

From victor.stinner at gmail.com  Fri Apr 14 08:29:00 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 14 Apr 2017 14:29:00 +0200
Subject: [pypy-dev] Tune performance benchmarks for PyPy
Message-ID: <CAMpsgwbL=EUmUF+RmgX1N9p3FJ2NUnODg3KJ2zwB6AqJKOCJvw@mail.gmail.com>

Hi,

I ran the performance benchmark suite with PyPy 5.7 on the
speed-python server, the benchmark runner feeding speed.python.org. I
chose to spawn 10 processes, each process computed 250 values. The
number of outer loops was calibrated per benchmark. Here are raw data:

http://www.haypocalc.com/tmp/pypy_p10_w0_n250.json.gz

The plan is now to choose the number of warmup values from these data
and copy the number of loops to get fixed parameters.

You can directly analyze the (compressed) JSON file using plot.py to
plot values:

https://github.com/haypo/perf/raw/master/doc/examples/plot.py

I suggest to use the --split-runs value to have one line per run (per process):

python3 doc/examples/plot.py ~/pypy_p10_w0_n250.json.gz -b telco --split-runs

It's likely that the first values are much larger: use the UI to zoom,
or pass --skip=N to skip the first N values of each run.

python3 doc/examples/plot.py ~/pypy_p10_w0_n250.json.gz -b telco
--split-runs --skip=3

Or you can only render one specific run:

python3 doc/examples/plot.py ~/pypy_p10_w0_n250.json.gz -b telco
--split-runs --run=2

The JSON file contains results of 67 benchmarks: use "python3 -m perf
show ~/pypy_p10_w0_n250.json.gz -q" to list them. plot.py script
requires a benchmark name (-b/--benchmark option).

The game is now to choose the number of values to skip to reach the
"steady state". plot.py renders the mean to help you ;-)

You can also use perf commands to analyze data:
* perf stats
* perf dump
* perf hist
* etc.

These commands can display all benchmarks, or only one if you use the -b option.

Or you can use perf API to export data and use whatever you want to
analyze data.

See also the perf doc:
http://perf.readthedocs.io/en/latest/analyze.html

Next week, I will try to do the work for each benchmark, and then I
will come back to you with numbers, so we can double-check together
that everything looks fine.

Parameters are likely to change depending on the CPU, PyPy version,
etc. But my first goal is to get reproductible results on speed-python
with the latest version of PyPy, so I will start with that. Later, we
can adjust parameters depending on the CPU and/or PyPy version.

Enjoy!
Victor

From frankw at mit.edu  Sun Apr 16 17:04:06 2017
From: frankw at mit.edu (Frank Wang)
Date: Sun, 16 Apr 2017 17:04:06 -0400
Subject: [pypy-dev] PyPy Benchmarks
Message-ID: <CAD=7XjMY6dc3XzgTfzrvpjumLxSEdtO5TJ22WZ1zQZtzjF2K6g@mail.gmail.com>

Hi,

I was wondering if there were a "standard" set of PyPy benchmarks that are
commonly used.

I'm currently using this: http://pyperformance.readthedocs.io/

Thanks,
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170416/a532a6f2/attachment.html>

From victor.stinner at gmail.com  Sun Apr 16 17:34:33 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 16 Apr 2017 23:34:33 +0200
Subject: [pypy-dev] PyPy Benchmarks
In-Reply-To: <CAD=7XjMY6dc3XzgTfzrvpjumLxSEdtO5TJ22WZ1zQZtzjF2K6g@mail.gmail.com>
References: <CAD=7XjMY6dc3XzgTfzrvpjumLxSEdtO5TJ22WZ1zQZtzjF2K6g@mail.gmail.com>
Message-ID: <CAMpsgwbS==JGEe2ze6STKY0Aza2NOxVWg3PZ8x+WrMAMhpxo0g@mail.gmail.com>

Hi,

speed.pypy.org uses https://bitbucket.org/pypy/benchmarks You are looking
for this benchmark suite.

I'm actively working on supporting PyPy in pyperformance. The doc should be
more explicit to explain that PyPy is not officially supported.

I mean that you can use performance on PyPy but benchmarks are not finely
tuned for PyPy and so you don't get best performance and results may be
unstable.

Victor

Le 16 avr. 2017 23:05, "Frank Wang" <frankw at mit.edu> a ?crit :

> Hi,
>
> I was wondering if there were a "standard" set of PyPy benchmarks that are
> commonly used.
>
> I'm currently using this: http://pyperformance.readthedocs.io/
>
> Thanks,
> Frank
>
> _______________________________________________
> 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/20170416/3c553e06/attachment.html>

From victor.stinner at gmail.com  Tue Apr 18 10:14:49 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 18 Apr 2017 16:14:49 +0200
Subject: [pypy-dev] Tune performance benchmarks for PyPy
In-Reply-To: <CAMpsgwbL=EUmUF+RmgX1N9p3FJ2NUnODg3KJ2zwB6AqJKOCJvw@mail.gmail.com>
References: <CAMpsgwbL=EUmUF+RmgX1N9p3FJ2NUnODg3KJ2zwB6AqJKOCJvw@mail.gmail.com>
Message-ID: <CAMpsgwYfqaATacHn6sW0hHa6XrpBH_PH9jCCQ+goO65sfk8kKw@mail.gmail.com>

2017-04-14 14:29 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> Here are raw data:
> http://www.haypocalc.com/tmp/pypy_p10_w0_n250.json.gz

I archived the file at:
https://github.com/haypo/performance_results/raw/master/2017-04-13-pypy/pypy2_571_warmups.json.gz

> Next week, I will try to do the work for each benchmark, and then I
> will come back to you with numbers, so we can double-check together
> that everything looks fine.

I started to document my analysis at:
http://haypo-notes.readthedocs.io/pypy_warmups.html

Victor

From frankw at mit.edu  Tue Apr 18 16:14:51 2017
From: frankw at mit.edu (Frank Wang)
Date: Tue, 18 Apr 2017 16:14:51 -0400
Subject: [pypy-dev] Socket Module
Message-ID: <CAD=7XjPt5WJ_WF0p7JfFbf0X6uKD98+fbmRV6kVE_m39F2X_pQ@mail.gmail.com>

Hi,

I want to modify the definition of socket.socket() to include an extra
parameter. I found this function (newsocket):

https://bitbucket.org/pypy/pypy/src/8175c5e20480b2c8e1b95c7f758458db7193f1a8/pypy/module/_socket/interp_socket.py?at=default&fileviewer=file-view-default#interp_socket.py-613

Is this the right function to modify? Since W_Socket inherits from W_Root,
in the socket call, I want to call a function in W_Root. Should I call it
on the space.wrap(self) object or just self? My question is more around
that "self" seems to be a wrapped interpreter object already, specifically
W_Socket. Why does it need to wrapped again? Unless I'm confused....

Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170418/e9883f77/attachment.html>

From frankw at mit.edu  Wed Apr 19 01:32:22 2017
From: frankw at mit.edu (Frank Wang)
Date: Wed, 19 Apr 2017 01:32:22 -0400
Subject: [pypy-dev] PyPy Benchmarks
In-Reply-To: <CAMpsgwbS==JGEe2ze6STKY0Aza2NOxVWg3PZ8x+WrMAMhpxo0g@mail.gmail.com>
References: <CAD=7XjMY6dc3XzgTfzrvpjumLxSEdtO5TJ22WZ1zQZtzjF2K6g@mail.gmail.com>
 <CAMpsgwbS==JGEe2ze6STKY0Aza2NOxVWg3PZ8x+WrMAMhpxo0g@mail.gmail.com>
Message-ID: <CAD=7XjP5bu-rJAQOUHtwxAsveBg85+b=utptuZMWA_CdqRF-_w@mail.gmail.com>

Awesome thanks, Victor! For https://bitbucket.org/pypy/benchmarks, is there
an explanation on what each of these benchmarks are? There doesn't seem to
be a README.

Frank

On Sun, Apr 16, 2017 at 5:34 PM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> speed.pypy.org uses https://bitbucket.org/pypy/benchmarks You are looking
> for this benchmark suite.
>
> I'm actively working on supporting PyPy in pyperformance. The doc should
> be more explicit to explain that PyPy is not officially supported.
>
> I mean that you can use performance on PyPy but benchmarks are not finely
> tuned for PyPy and so you don't get best performance and results may be
> unstable.
>
> Victor
>
> Le 16 avr. 2017 23:05, "Frank Wang" <frankw at mit.edu> a ?crit :
>
>> Hi,
>>
>> I was wondering if there were a "standard" set of PyPy benchmarks that
>> are commonly used.
>>
>> I'm currently using this: http://pyperformance.readthedocs.io/
>>
>> Thanks,
>> Frank
>>
>> _______________________________________________
>> 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/20170419/025dd03b/attachment.html>

From victor.stinner at gmail.com  Wed Apr 19 07:03:47 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 19 Apr 2017 13:03:47 +0200
Subject: [pypy-dev] PyPy Benchmarks
In-Reply-To: <CAD=7XjP5bu-rJAQOUHtwxAsveBg85+b=utptuZMWA_CdqRF-_w@mail.gmail.com>
References: <CAD=7XjMY6dc3XzgTfzrvpjumLxSEdtO5TJ22WZ1zQZtzjF2K6g@mail.gmail.com>
 <CAMpsgwbS==JGEe2ze6STKY0Aza2NOxVWg3PZ8x+WrMAMhpxo0g@mail.gmail.com>
 <CAD=7XjP5bu-rJAQOUHtwxAsveBg85+b=utptuZMWA_CdqRF-_w@mail.gmail.com>
Message-ID: <CAMpsgwaEWfq0ptrYdpLoQTrtr28yZdw3fFfMwm8sTMSxZ02WnA@mail.gmail.com>

2017-04-19 7:32 GMT+02:00 Frank Wang <frankw at mit.edu>:
> Awesome thanks, Victor! For https://bitbucket.org/pypy/benchmarks, is there
> an explanation on what each of these benchmarks are? There doesn't seem to
> be a README.

performance shares many benchmarks, so you can first look at
performance documentation:
http://pyperformance.readthedocs.io/benchmarks.html#available-benchmarks

Victor

From zdenek.bouska at gmail.com  Thu Apr 20 04:37:18 2017
From: zdenek.bouska at gmail.com (Zdenek Bouska)
Date: Thu, 20 Apr 2017 10:37:18 +0200
Subject: [pypy-dev] Cross-translating for ARM on Ubuntu 16.04
Message-ID: <CAJiYBq5dd8gkWEFqGBB6g7WwuUuCAfOpSsOzSbF6Ah11o8SThQ@mail.gmail.com>

Hi,

I would like to cross-translate pypy for armhf (Beagle Bone Black) on
amd64 hardware running Ubuntu 16.04.

I tried it using http://doc.pypy.org/en/release-2.4.x/arm.html (linked from
but failed because Ubuntu 16.04 does not have scratchbox2 package.
Scratchbox2 is no longer maintained according to Wikipedia.

Does anyone here successfully cross-translated PyPy without scratchbox2?

Regards

Zdenek

From tinchester at gmail.com  Fri Apr 21 04:05:53 2017
From: tinchester at gmail.com (=?UTF-8?Q?Tin_Tvrtkovi=C4=87?=)
Date: Fri, 21 Apr 2017 08:05:53 +0000
Subject: [pypy-dev] Sigsegv from Cython
Message-ID: <CAEJ-mUqALxRNzAVrf6gUhRbsKOZOG+vHu_OmN14na894KYn1LQ@mail.gmail.com>

Hello,

I'm working on a feature for the attrs library. As part of that feature I
need to wrap the member_descriptor descriptor from ordinary slot classes.
In order to speed this up, I'm using Cython.

I'm not really sure if this or the Cython mailing list is the right place
to ask this, but since I've had better luck here in the past I'm posting
this here first :)

A quick reproducer: Ubuntu 17.04/amd64, make a PyPy 5.7.1 venv, pip install
Cython, download
https://gist.github.com/Tinche/678a2f97f656421ab65338ea678df354 and
https://gist.github.com/Tinche/111ccd2f46c9ba303b8e441d2e0fcddb. Uncomment
the last line in t.py to trigger the crash.

This code seems to work on CPython (and it speeds up attribute access a lot
there). I'm not even sure doing this on PyPy is worthwhile, but as long as
it crashes I can't be sure :)

I'll be the first to admit I don't have a lot of experience writing Cython
or C, so maybe there's an amateur mistake in there. For example, I tried
putting in a few Py_INCREFs to maybe stop PyPy from moving objects around
but it doesn't seem to help.

Thanks in advance: :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20170421/7e6ea9cc/attachment.html>

From matti.picus at gmail.com  Fri Apr 21 10:36:33 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Fri, 21 Apr 2017 17:36:33 +0300
Subject: [pypy-dev] Sigsegv from Cython
In-Reply-To: <CAEJ-mUqALxRNzAVrf6gUhRbsKOZOG+vHu_OmN14na894KYn1LQ@mail.gmail.com>
References: <CAEJ-mUqALxRNzAVrf6gUhRbsKOZOG+vHu_OmN14na894KYn1LQ@mail.gmail.com>
Message-ID: <f9f9b8f0-4951-f1ee-726e-f1633a8f316a@gmail.com>

Please file an issue on https://bitbucket.org/pypy/pypy/issues so this 
doesn't get lost, I will try to take a look.
Note that you probably will not see any speed up since our c-to-rpython 
conversion layer is much slower than cpython.
Matti

On 21/04/17 11:05, Tin Tvrtkovi? wrote:
> Hello,
>
> I'm working on a feature for the attrs library. As part of that 
> feature I need to wrap the member_descriptor descriptor from ordinary 
> slot classes. In order to speed this up, I'm using Cython.
>
> I'm not really sure if this or the Cython mailing list is the right 
> place to ask this, but since I've had better luck here in the past I'm 
> posting this here first :)
>
> A quick reproducer: Ubuntu 17.04/amd64, make a PyPy 5.7.1 venv, pip 
> install Cython, download 
> https://gist.github.com/Tinche/678a2f97f656421ab65338ea678df354 and 
> https://gist.github.com/Tinche/111ccd2f46c9ba303b8e441d2e0fcddb. 
> Uncomment the last line in t.py to trigger the crash.
>
> This code seems to work on CPython (and it speeds up attribute access 
> a lot there). I'm not even sure doing this on PyPy is worthwhile, but 
> as long as it crashes I can't be sure :)
>
> I'll be the first to admit I don't have a lot of experience writing 
> Cython or C, so maybe there's an amateur mistake in there. For 
> example, I tried putting in a few Py_INCREFs to maybe stop PyPy from 
> moving objects around but it doesn't seem to help.
>
> Thanks in advance: :)
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev


From matti.picus at gmail.com  Mon Apr 24 12:47:21 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 24 Apr 2017 19:47:21 +0300
Subject: [pypy-dev] win32 buildbot
Message-ID: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>

Any volunteers to host a win32 buildbot slave?

It would be nice to have at least two machines online, since the 
processes seem so slow on that platform.

The current builder has gotten stuck and the maintainer is not 
responding to emails, we are down to no functioning buildbot slaves for 
that platform.

Minimum requirements are:

- relatively new hardware

- at least 8GB memory

- 5 GB disk space for pypy (not including OS and visual studio)

- internet connection

I looked into an Azure vm, but from what I could tell it would be about 
$10 per translation, and maybe more for an own-tests run, since the 
machines with significant RAM are expensive. We tried once to get 
Microsoft to donate some credits, but that did not go far.

Matti


From yury at shurup.com  Sat Apr 29 06:41:30 2017
From: yury at shurup.com (Yury V. Zaytsev)
Date: Sat, 29 Apr 2017 12:41:30 +0200 (CEST)
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
Message-ID: <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>

On Mon, 24 Apr 2017, Matti Picus wrote:

> Any volunteers to host a win32 buildbot slave?
>
> It would be nice to have at least two machines online, since the processes 
> seem so slow on that platform.
>
> The current builder has gotten stuck and the maintainer is not responding to 
> emails, we are down to no functioning buildbot slaves for that platform.

Hi Matti,

Sorry for the delay, I've been on a fully offline vacation, and have just 
opened my inbox (with horror) to find your emails among thousands of 
others. I'm still travelling, but I will be back home in a couple of days 
and will have a look into the win32 builder as soon as I get access to my 
computer...

Maybe we should have another go at trying to activate the damn MSDN 
subscription. The last time I've eventually given up after dozens of 
emails, as I had few other pressing issues to resolve...

-- 
Sincerely yours,
Yury V. Zaytsev

From matti.picus at gmail.com  Sat Apr 29 13:38:01 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Sat, 29 Apr 2017 20:38:01 +0300
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
 <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
Message-ID: <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>

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

From yury at shurup.com  Sat Apr 29 23:15:21 2017
From: yury at shurup.com (Yury V. Zaytsev)
Date: Sun, 30 Apr 2017 05:15:21 +0200 (CEST)
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
 <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
 <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
Message-ID: <alpine.LRH.2.20.1704300508300.1722@vps.zaytsev.net>

On Sat, 29 Apr 2017, Matti Picus wrote:

> Cool, hope you had a good vacation. Looking forward to hearing from you 
> when you get settled.

Yeah, it was pretty awesome, especially the offline aspect ;-) , but sure 
enough the servers go on strike as soon as I'm AFK, so busy times ahead...

> As for MSDN, you have another set of mails about that :), the bottom 
> line is that we have tried Azure, and are waiting for answers from 
> Microsoft how to proceed.

It seems that I wasn't on CC, so would you care to forward relevant stuff 
if there is anything I could help you with? I think you have everything I 
had so far, the last state I'm aware of was that the MSDN code was issued, 
but I couldn't activate it due to an unknown issue with the website, and 
so we needed to use the official support channel for that, which in the 
end I didn't get to...

-- 
Sincerely yours,
Yury V. Zaytsev

From yury at shurup.com  Sun Apr 30 15:39:02 2017
From: yury at shurup.com (Yury V. Zaytsev)
Date: Sun, 30 Apr 2017 21:39:02 +0200 (CEST)
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
 <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
 <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
Message-ID: <alpine.LRH.2.20.1704302134080.1722@vps.zaytsev.net>

On Sat, 29 Apr 2017, Matti Picus wrote:

> Cool, hope you had a good vacation. Looking forward to hearing from you 
> when you get settled.

I've just had a look at the build slave, and it seems that it's the usual 
problem with Windows sucking in some updates but failing to restart 
properly or whatever. I did some minor cleanups and it looks like it's 
running again, but could someone with access to buildbot please restart 
it? There is a job stuck there that I'm unable to remove no matter what:

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

I didn't have a look into updating the libraries yet, but hopefully will 
get to it sometime this week (?!)...

-- 
Sincerely yours,
Yury V. Zaytsev

From matti.picus at gmail.com  Sun Apr 30 16:09:08 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Sun, 30 Apr 2017 23:09:08 +0300
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <alpine.LRH.2.20.1704302134080.1722@vps.zaytsev.net>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
 <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
 <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
 <alpine.LRH.2.20.1704302134080.1722@vps.zaytsev.net>
Message-ID: <5eac3717-e805-3f94-c3b6-5e35c15a7c5f@gmail.com>

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

From yury at shurup.com  Sun Apr 30 16:14:56 2017
From: yury at shurup.com (Yury V. Zaytsev)
Date: Sun, 30 Apr 2017 22:14:56 +0200 (CEST)
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <5eac3717-e805-3f94-c3b6-5e35c15a7c5f@gmail.com>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
 <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
 <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
 <alpine.LRH.2.20.1704302134080.1722@vps.zaytsev.net>
 <5eac3717-e805-3f94-c3b6-5e35c15a7c5f@gmail.com>
Message-ID: <alpine.LRH.2.20.1704302212260.1722@vps.zaytsev.net>

On Sun, 30 Apr 2017, Matti Picus wrote:

> We cannot kill it from the buildbot master side. I'm pretty sure I've 
> seen this before, where hg just hangs, and the only solution is to kill 
> the buildslave process on the win32 machine (which may involve a 
> reboot).

No, the process doesn't exist on the slave, precisely because it has been 
rebooted multiple times in the mean time, but the master is confused about 
it and believes that the build is still running.

-- 
Sincerely yours,
Yury V. Zaytsev

From matti.picus at gmail.com  Sun Apr 30 16:33:43 2017
From: matti.picus at gmail.com (Matti Picus)
Date: Sun, 30 Apr 2017 23:33:43 +0300
Subject: [pypy-dev] win32 buildbot
In-Reply-To: <alpine.LRH.2.20.1704302212260.1722@vps.zaytsev.net>
References: <8cc03a45-270d-ec7e-ef7c-b8bb585bf44e@gmail.com>
 <alpine.LRH.2.20.1704291232400.1722@vps.zaytsev.net>
 <7c07cdd2-6e2f-656f-5848-d7f0ab24e8a6@gmail.com>
 <alpine.LRH.2.20.1704302134080.1722@vps.zaytsev.net>
 <5eac3717-e805-3f94-c3b6-5e35c15a7c5f@gmail.com>
 <alpine.LRH.2.20.1704302212260.1722@vps.zaytsev.net>
Message-ID: <d384c5d3-045d-f0b5-39f7-93cb9011e03e@gmail.com>

On 30/04/17 23:14, Yury V. Zaytsev wrote:

> On Sun, 30 Apr 2017, Matti Picus wrote:
>
>> We cannot kill it from the buildbot master side. I'm pretty sure I've 
>> seen this before, where hg just hangs, and the only solution is to 
>> kill the buildslave process on the win32 machine (which may involve a 
>> reboot).
>
> No, the process doesn't exist on the slave, precisely because it has 
> been rebooted multiple times in the mean time, but the master is 
> confused about it and believes that the build is still running.
>
My bad, restarting the build master seems to have stopped that job.
Before nightlies run you may want to check that "hg pull" can run in 
that directory c:\pypy\buildbot\pypy-c-jit-win-x86-32\build