From ndbecker2 at gmail.com  Thu Sep  1 13:54:20 2016
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 01 Sep 2016 13:54:20 -0400
Subject: [pypy-dev] numpy import error (pypy3)
Message-ID: <nq9q0b$smf$1@blaine.gmane.org>

Newb here, trying out pypy3.  Used pip3 to install numpy with no error, but 
doesn't work:

 ~/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/bin/pypy3
Python 3.3.5 (27fa55f3a61023d76af3b38f34d1401b0b186076, May 31 2016, 
17:54:15)
[PyPy 5.2.0-alpha0 with GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``the future has just begun''
>>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/site-
packages/numpy/__init__.py", line 180, in <module>
    from . import add_newdocs
  File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/site-
packages/numpy/add_newdocs.py", line 13, in <module>
    from numpy.lib import add_newdoc
  File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/site-
packages/numpy/lib/__init__.py", line 8, in <module>
    from .type_check import *
  File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/site-
packages/numpy/lib/type_check.py", line 11, in <module>
    import numpy.core.numeric as _nx
  File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/site-
packages/numpy/core/__init__.py", line 14, in <module>
    from . import multiarray
ImportError: unable to load extension module '/home/nbecker/pypy3.3-5.2-
alpha-20160602-linux_x86_64-portable/site-
packages/numpy/core/multiarray.pypy3-52.so': /home/nbecker/pypy3.3-5.2-
alpha-20160602-linux_x86_64-portable/site-
packages/numpy/core/multiarray.pypy3-52.so: undefined symbol: 
PyBytes_FromFormat
>>>> 


From matti.picus at gmail.com  Thu Sep  1 14:09:05 2016
From: matti.picus at gmail.com (matti picus)
Date: Thu, 1 Sep 2016 21:09:05 +0300
Subject: [pypy-dev] numpy import error (pypy3)
In-Reply-To: <nq9q0b$smf$1@blaine.gmane.org>
References: <nq9q0b$smf$1@blaine.gmane.org>
Message-ID: <CAO8bCgjUq0_tnNv35WAcTpfD93uunrKRLq0TiaZ+oSO9Av7oXw@mail.gmail.com>

On Thursday, 1 September 2016, Neal Becker <ndbecker2 at gmail.com> wrote:

> Newb here, trying out pypy3.  Used pip3 to install numpy with no error, but
> doesn't work:
>
>  ~/pypy3.3-5.2-alpha-20160602-linux_x86_64-portable/bin/pypy3
> Python 3.3.5 (27fa55f3a61023d76af3b38f34d1401b0b186076, May 31 2016,
> 17:54:15)
> [PyPy 5.2.0-alpha0 with GCC 4.9.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> And now for something completely different: ``the future has just begun''
> >>>> import numpy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-
> portable/site-
> packages/numpy/__init__.py", line 180, in <module>
>     from . import add_newdocs
>   File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-
> portable/site-
> packages/numpy/add_newdocs.py", line 13, in <module>
>     from numpy.lib import add_newdoc
>   File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-
> portable/site-
> packages/numpy/lib/__init__.py", line 8, in <module>
>     from .type_check import *
>   File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-
> portable/site-
> packages/numpy/lib/type_check.py", line 11, in <module>
>     import numpy.core.numeric as _nx
>   File "/home/nbecker/pypy3.3-5.2-alpha-20160602-linux_x86_64-
> portable/site-
> packages/numpy/core/__init__.py", line 14, in <module>
>     from . import multiarray
> ImportError: unable to load extension module '/home/nbecker/pypy3.3-5.2-
> alpha-20160602-linux_x86_64-portable/site-
> packages/numpy/core/multiarray.pypy3-52.so': /home/nbecker/pypy3.3-5.2-
> alpha-20160602-linux_x86_64-portable/site-
> packages/numpy/core/multiarray.pypy3-52.so: undefined symbol:
> PyBytes_FromFormat
> >>>>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/pypy-dev
>

Numpy is not supported on pypy3.x, the cpyext layer is not complete. Even
on pypy2.7 you should use the latest developer version of numpy to get the
patches we submitted.
Matti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160901/a4f0bc60/attachment.html>

From stuaxo2 at yahoo.com  Sat Sep  3 09:56:25 2016
From: stuaxo2 at yahoo.com (Stuart Axon)
Date: Sat, 3 Sep 2016 13:56:25 +0000 (UTC)
Subject: [pypy-dev] sysconfig.get_path('include') incorrect in virtualenv
References: <1898843327.790778.1472910985924.ref@mail.yahoo.com>
Message-ID: <1898843327.790778.1472910985924@mail.yahoo.com>

If I create a virtualenv: ?/mnt/data/home/stu/.virtualenvs/pypy-venv
Then run try and get the include path using sysconfig it is incorrect:
>>>> import sysconfig>>>> sysconfig.get_path('include')'/mnt/data/home/stu/local/include'?
It should be:/mnt/data/home/stu/.virtualenvs/pypy-venv/include
or possibly where that symlink points to:/usr/lib/pypy/include

This then affects python-config which means I get stuck trying to compile pygobject.


S++
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160903/e20ec1fa/attachment.html>

From stuaxo2 at yahoo.com  Sat Sep  3 11:02:15 2016
From: stuaxo2 at yahoo.com (Stuart Axon)
Date: Sat, 3 Sep 2016 15:02:15 +0000 (UTC)
Subject: [pypy-dev] sysconfig.get_path('include') incorrect in virtualenv
In-Reply-To: <1898843327.790778.1472910985924@mail.yahoo.com>
References: <1898843327.790778.1472910985924.ref@mail.yahoo.com>
 <1898843327.790778.1472910985924@mail.yahoo.com>
Message-ID: <1252075596.803428.1472914935477@mail.yahoo.com>

A bit more info:
sysconfig._get_default_scheme() returns 'pypy-local'. ? ?If I change this to return 'pypy' then the include path is correct.
I'm not fully sure how it supposed to decide between the two ??S++ 

    On Saturday, September 3, 2016 2:56 PM, Stuart Axon via pypy-dev <pypy-dev at python.org> wrote:
 
 

 If I create a virtualenv: ?/mnt/data/home/stu/.virtualenvs/pypy-venv
Then run try and get the include path using sysconfig it is incorrect:
>>>> import sysconfig>>>> sysconfig.get_path('include')'/mnt/data/home/stu/local/include'?
It should be:/mnt/data/home/stu/.virtualenvs/pypy-venv/include
or possibly where that symlink points to:/usr/lib/pypy/include

This then affects python-config which means I get stuck trying to compile pygobject.


S++
_______________________________________________
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/20160903/74359381/attachment.html>

From stuaxo2 at yahoo.com  Sat Sep  3 11:20:43 2016
From: stuaxo2 at yahoo.com (Stuart Axon)
Date: Sat, 3 Sep 2016 15:20:43 +0000 (UTC)
Subject: [pypy-dev] sysconfig.get_path('include') incorrect in virtualenv
In-Reply-To: <1252075596.803428.1472914935477@mail.yahoo.com>
References: <1898843327.790778.1472910985924.ref@mail.yahoo.com>
 <1898843327.790778.1472910985924@mail.yahoo.com>
 <1252075596.803428.1472914935477@mail.yahoo.com>
Message-ID: <164540153.782978.1472916043499@mail.yahoo.com>

Moved to issue 2392 - I probably need to do a bit more testing on sysconfig of the different paths:https://bitbucket.org/pypy/pypy/issues/2392/differences-with-sysconfig

?S++ 

    On Saturday, September 3, 2016 4:02 PM, Stuart Axon <stuaxo2 at yahoo.com> wrote:
 
 

 A bit more info:
sysconfig._get_default_scheme() returns 'pypy-local'. ? ?If I change this to return 'pypy' then the include path is correct.
I'm not fully sure how it supposed to decide between the two ??S++ 

    On Saturday, September 3, 2016 2:56 PM, Stuart Axon via pypy-dev <pypy-dev at python.org> wrote:
 
 

 If I create a virtualenv: ?/mnt/data/home/stu/.virtualenvs/pypy-venv
Then run try and get the include path using sysconfig it is incorrect:
>>>> import sysconfig>>>> sysconfig.get_path('include')'/mnt/data/home/stu/local/include'?
It should be:/mnt/data/home/stu/.virtualenvs/pypy-venv/include
or possibly where that symlink points to:/usr/lib/pypy/include

This then affects python-config which means I get stuck trying to compile pygobject.


S++
_______________________________________________
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/20160903/d50d29db/attachment-0001.html>

From matti.picus at gmail.com  Mon Sep  5 16:25:24 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 5 Sep 2016 23:25:24 +0300
Subject: [pypy-dev] PyPy bug release 5.4.1
Message-ID: <a0bfd68a-9df1-6122-5259-5a4e70d6b232@gmail.com>

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

From peter.xihong.wang at intel.com  Wed Sep  7 15:10:19 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Wed, 7 Sep 2016 19:10:19 +0000
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
 <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
 <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>

HI Yury,

Thanks for clarifying on this.  
Also want to take this opportunity to thank William for the initial answer.

We did notice fancy screen output during the build process to demonstrate the build progress, and I am wondering if a build option could be made to disable the output, which may save some valuable build time.
Just a thought.

Thanks,

Peter

?
-----Original Message-----
From: Yury V. Zaytsev [mailto:yury at shurup.com] 
Sent: Wednesday, September 07, 2016 12:03 PM
To: William ML Leslie <william.leslie.ttg at gmail.com>
Cc: Wang, Peter Xihong <peter.xihong.wang at intel.com>; PyPy Developer Mailing List <pypy-dev at python.org>
Subject: Re: [pypy-dev] Any known tricks or effort made to make the PyPy source code build faster?

On Tue, 30 Aug 2016, William ML Leslie wrote:

> > On 30/08/2016 9:53 am, "Wang, Peter Xihong" 
> > <peter.xihong.wang at intel.com> wrote:
> > 
> > By default, it appears most of the time during the build/compile 
> > process, only 1 single CPU core is busy, signaling missing of 
> > parallel compiling.  Is there any best known practice to make it faster?
> 
> Not at the moment. The STM work that Armin is doing may give us an 
> interpreter that can make better use of extra cores during 
> translation, but it is still experimental.

Just to elaborate on this as it might be not obvious for the newcomers: 
most of the "build" time is actually *not* spent upon compilation itself (as with many other projects), but rather upon translation of the interpreter into the source code, which is to be compiled into the binary during the last step of the build.

This last step can be easily parallelized with make, however, because of the above, this has little practical value. Unfortunately, parallelization of the translation process is challenging due to the GIL issue. The
(amazing) STM work as mentioned by William sidesteps this problem, but, at the moment, it is not ready yet.

-- 
Sincerely yours,
Yury V. Zaytsev

From yury at shurup.com  Wed Sep  7 15:02:53 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Wed, 7 Sep 2016 21:02:53 +0200 (CEST)
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
 <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>

On Tue, 30 Aug 2016, William ML Leslie wrote:

> > On 30/08/2016 9:53 am, "Wang, Peter Xihong" 
> > <peter.xihong.wang at intel.com> wrote:
> > 
> > By default, it appears most of the time during the build/compile 
> > process, only 1 single CPU core is busy, signaling missing of parallel 
> > compiling.  Is there any best known practice to make it faster?
> 
> Not at the moment. The STM work that Armin is doing may give us an 
> interpreter that can make better use of extra cores during translation, 
> but it is still experimental.

Just to elaborate on this as it might be not obvious for the newcomers: 
most of the "build" time is actually *not* spent upon compilation itself 
(as with many other projects), but rather upon translation of the 
interpreter into the source code, which is to be compiled into the binary 
during the last step of the build.

This last step can be easily parallelized with make, however, because of 
the above, this has little practical value. Unfortunately, parallelization 
of the translation process is challenging due to the GIL issue. The 
(amazing) STM work as mentioned by William sidesteps this problem, but, at 
the moment, it is not ready yet.

-- 
Sincerely yours,
Yury V. Zaytsev

From yury at shurup.com  Wed Sep  7 15:26:59 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Wed, 7 Sep 2016 21:26:59 +0200 (CEST)
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
 <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
 <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>
 <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>
Message-ID: <alpine.LRH.2.20.1609072123040.1556@vps.zaytsev.net>

On Wed, 7 Sep 2016, Wang, Peter Xihong wrote:

> We did notice fancy screen output during the build process to 
> demonstrate the build progress, and I am wondering if a build option 
> could be made to disable the output, which may save some valuable build 
> time. Just a thought.

I understand that you are referring to the trademark Mandelbrot fractal; 
if that's the case, then, well, you might be able to save a few seconds on 
a several hours translation if you remove it, but I doubt that this would 
really help your cause...

I would say that the most promising approach so far would be to fund 
and/or help with the STM work ;-)

-- 
Sincerely yours,
Yury V. Zaytsev

From yury at shurup.com  Wed Sep  7 16:07:34 2016
From: yury at shurup.com (Yury V. Zaytsev)
Date: Wed, 7 Sep 2016 22:07:34 +0200 (CEST)
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
 <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
 <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>
 <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>
Message-ID: <alpine.LRH.2.20.1609072202180.1556@vps.zaytsev.net>

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

Now that I think about it, there is yet another not obvious "trick" that I 
should have probably mentioned:

You should definitively be translating PyPy with PyPy itself (rather than 
CPython); even though it will still use only 1 core, the translation will 
greatly benefit from the JIT. It's been a very long while since I've last 
checked, but I wouldn't be surprised about a factor 2x speedup or so...

-- 
Sincerely yours,
Yury V. Zaytsev

From cfbolz at gmx.de  Wed Sep  7 16:26:11 2016
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 7 Sep 2016 22:26:11 +0200
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <alpine.LRH.2.20.1609072202180.1556@vps.zaytsev.net>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
 <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
 <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>
 <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>
 <alpine.LRH.2.20.1609072202180.1556@vps.zaytsev.net>
Message-ID: <aee1a730-5fbd-d4f9-6590-ee109295f521@gmx.de>

On 07/09/16 22:07, Yury V. Zaytsev wrote:
>> On 30/08/2016 9:53 am, "Wang, Peter Xihong"
>> <peter.xihong.wang at intel.com> wrote:
>>
>> By default, it appears most of the time during the build/compile
>> process, only 1 single CPU core is busy, signaling missing of parallel
>> compiling.  Is there any best known practice to make it faster?
> 
> Now that I think about it, there is yet another not obvious "trick" that
> I should have probably mentioned:
> 
> You should definitively be translating PyPy with PyPy itself (rather
> than CPython); even though it will still use only 1 core, the
> translation will greatly benefit from the JIT. It's been a very long
> while since I've last checked, but I wouldn't be surprised about a
> factor 2x speedup or so...
> 

Yes, that's correct: translating pypy with itself is significantly
faster.

The Mandelbrot fractal takes not many seconds to compute, so is not
really a problem.

Cheers,

Carl Friedrich

From peter.xihong.wang at intel.com  Wed Sep  7 18:44:40 2016
From: peter.xihong.wang at intel.com (Wang, Peter Xihong)
Date: Wed, 7 Sep 2016 22:44:40 +0000
Subject: [pypy-dev] Any known tricks or effort made to make the PyPy
 source code build faster?
In-Reply-To: <alpine.LRH.2.20.1609072202180.1556@vps.zaytsev.net>
References: <371EBC7881C7844EAAF5556BFF21BCCC42E275B3@ORSMSX105.amr.corp.intel.com>
 <CAHgd1hF+BsoszYQZamZ6yXXc8MTgibpMhAJP+jec2rKtGkykAg@mail.gmail.com>
 <alpine.LRH.2.20.1609072051390.1556@vps.zaytsev.net>
 <371EBC7881C7844EAAF5556BFF21BCCC42E2B3C3@ORSMSX105.amr.corp.intel.com>
 <alpine.LRH.2.20.1609072202180.1556@vps.zaytsev.net>
Message-ID: <371EBC7881C7844EAAF5556BFF21BCCC42E2B56E@ORSMSX105.amr.corp.intel.com>

That's a great tip, :-).  Just done with an experiment, and PyPy2 5.4.1-alpha0 cut down build time by 27% compared with CPython2.7.6
?
Thanks!

Peter


-----Original Message-----
From: Yury V. Zaytsev [mailto:yury at shurup.com] 
Sent: Wednesday, September 07, 2016 1:08 PM
To: Wang, Peter Xihong <peter.xihong.wang at intel.com>
Cc: William ML Leslie <william.leslie.ttg at gmail.com>; PyPy Developer Mailing List <pypy-dev at python.org>
Subject: RE: [pypy-dev] Any known tricks or effort made to make the PyPy source code build faster?

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

Now that I think about it, there is yet another not obvious "trick" that I should have probably mentioned:

You should definitively be translating PyPy with PyPy itself (rather than CPython); even though it will still use only 1 core, the translation will greatly benefit from the JIT. It's been a very long while since I've last checked, but I wouldn't be surprised about a factor 2x speedup or so...

--
Sincerely yours,
Yury V. Zaytsev

From janbrohl at t-online.de  Thu Sep  8 05:40:32 2016
From: janbrohl at t-online.de (Jan Brohl)
Date: Thu, 8 Sep 2016 11:40:32 +0200
Subject: [pypy-dev] Build Pypy with different Interpreters
Message-ID: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>

Is it possible to build different interpreters like Stackless, 
IronPython or Jython?

If not - why?

If yes - is it (in theory) possible to gain a speedup on those without 
GIL? (Is there multithreading at all the in translation process?)

Thanks,
Jan

From william.leslie.ttg at gmail.com  Thu Sep  8 08:07:50 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Thu, 8 Sep 2016 22:07:50 +1000
Subject: [pypy-dev] Build Pypy with different Interpreters
In-Reply-To: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>
References: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>
Message-ID: <CAHgd1hG5ox52HaJcHHFPbK7E+woWyHKokJUzb2V_F-97rjVjvg@mail.gmail.com>

On 8 September 2016 at 19:40, Jan Brohl <janbrohl at t-online.de> wrote:

> Is it possible to build different interpreters like Stackless, IronPython
> or Jython?
>

?That was actually the original motivation for creating pypy - maintaining
all those different python implementations was a lot of unnecessary work.
 ?Stackless support is enabled by default.  Support for translating to CLI
and the JVM was eventually dropped for lack of interest.  If someone wanted
to re-add that support, they could learn from the mistakes that the
previous implementation used.

http://doc.pypy.org/en/latest/stackless.html



>
> If not - why?
>
> If yes - is it (in theory) possible to gain a speedup on those without
> GIL? (Is there multithreading at all the in translation process?)
>

?Translation can't be done concurrently at the moment.  I probably should
have expanded upon this in my previous email, and maybe I will; there are a
number of global structures, registries, and work lists that would need to
be refactored before the translation work could be distributed.  If that's
the route the pypy team go, we will consider it ?after pypy itself supports
parallelism.

?There's another route, which is to support separate compilation, and then
to hand off the translation of built-in modules to different executors.?
 This is itself quite a bit of work due to some inherent properties of
rpython.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered under
copyright law.  You absolutely MAY reproduce any part of it in accordance
with the copyright law of the nation you are reading this in.  Any attempt
to DENY YOU THOSE RIGHTS would be illegal without prior contractual
agreement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160908/a1b72043/attachment.html>

From janbrohl at t-online.de  Thu Sep  8 08:38:27 2016
From: janbrohl at t-online.de (Jan Brohl)
Date: Thu, 8 Sep 2016 14:38:27 +0200
Subject: [pypy-dev] Build Pypy with different Interpreters
In-Reply-To: <CAHgd1hG5ox52HaJcHHFPbK7E+woWyHKokJUzb2V_F-97rjVjvg@mail.gmail.com>
References: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>
 <CAHgd1hG5ox52HaJcHHFPbK7E+woWyHKokJUzb2V_F-97rjVjvg@mail.gmail.com>
Message-ID: <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>

Sorry, for the typo - I was asking if it is possible to build pypy 
*with* different interpreters instead of just cpython and pypy.

(using eg "ipy64" instead of "pypy" or "python" in the translation step 
described at
http://doc.pypy.org/en/latest/build.html#run-the-translation )


Am 08.09.2016 um 14:07 schrieb William ML Leslie:
> On 8 September 2016 at 19:40, Jan Brohl <janbrohl at t-online.de
> <mailto:janbrohl at t-online.de>>wrote:
>
>     Is it possible to build different interpreters like Stackless,
>     IronPython or Jython?
>
>
> ?That was actually the original motivation for creating pypy -
> maintaining all those different python implementations was a lot of
> unnecessary work.  ?Stackless support is enabled by default.  Support
> for translating to CLI and the JVM was eventually dropped for lack of
> interest.  If someone wanted to re-add that support, they could learn
> from the mistakes that the previous implementation used.
>
> http://doc.pypy.org/en/latest/stackless.html
>
>
>
>
>     If not - why?
>
>     If yes - is it (in theory) possible to gain a speedup on those
>     without GIL? (Is there multithreading at all the in translation
>     process?)
>
>
> ?Translation can't be done concurrently at the moment.  I probably
> should have expanded upon this in my previous email, and maybe I will;
> there are a number of global structures, registries, and work lists that
> would need to be refactored before the translation work could be
> distributed.  If that's the route the pypy team go, we will consider it
> ?after pypy itself supports parallelism.
>
> ?There's another route, which is to support separate compilation, and
> then to hand off the translation of built-in modules to different
> executors.?  This is itself quite a bit of work due to some inherent
> properties of rpython.
>
> --
> William Leslie
>
> Notice:
> Likely much of this email is, by the nature of copyright, covered under
> copyright law.  You absolutely MAY reproduce any part of it in
> accordance with the copyright law of the nation you are reading this
> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior
> contractual agreement.

From william.leslie.ttg at gmail.com  Thu Sep  8 09:07:12 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Thu, 8 Sep 2016 23:07:12 +1000
Subject: [pypy-dev] Build Pypy with different Interpreters
In-Reply-To: <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>
References: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>
 <CAHgd1hG5ox52HaJcHHFPbK7E+woWyHKokJUzb2V_F-97rjVjvg@mail.gmail.com>
 <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>
Message-ID: <CAHgd1hEevd0G15jC4cRhzKzCq_7aUeyxsJsk20EXRz67mNDsfQ@mail.gmail.com>

On 8 September 2016 at 22:38, Jan Brohl <janbrohl at t-online.de> wrote:

> Sorry, for the typo - I was asking if it is possible to build pypy *with*
> different interpreters instead of just cpython and pypy.
>

?That makes sense, it fits with your other question (:

The translator operates on functions that have been byte-compiled by the
host compiler.  IronPython and Jython compile directly to their
corresponding virtual machine, so there's no cpython or pypy bytecode
available?.


> (using eg "ipy64" instead of "pypy" or "python" in the translation step
> described at
> http://doc.pypy.org/en/latest/build.html#run-the-translation )
>
>
-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered under
copyright law.  You absolutely MAY reproduce any part of it in accordance
with the copyright law of the nation you are reading this in.  Any attempt
to DENY YOU THOSE RIGHTS would be illegal without prior contractual
agreement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160908/b1fb0ffb/attachment.html>

From william.leslie.ttg at gmail.com  Thu Sep  8 10:49:19 2016
From: william.leslie.ttg at gmail.com (William ML Leslie)
Date: Fri, 9 Sep 2016 00:49:19 +1000
Subject: [pypy-dev] Build Pypy with different Interpreters
In-Reply-To: <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>
References: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>
 <CAHgd1hG5ox52HaJcHHFPbK7E+woWyHKokJUzb2V_F-97rjVjvg@mail.gmail.com>
 <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>
Message-ID: <CAHgd1hFWFUZ35pO92oRfONrrh_Rgz3Tf7zbYQuDSz82=nnKmeg@mail.gmail.com>

On 8 September 2016 at 22:38, Jan Brohl <janbrohl at t-online.de> wrote:

> Sorry, for the typo - I was asking if it is possible to build pypy *with*
> different interpreters instead of just cpython and pypy.
>
> (using eg "ipy64" instead of "pypy" or "python" in the translation step
> described at
> http://doc.pypy.org/en/latest/build.html#run-the-translation )
>
>
I didn't say anything about Stackless; maybe I should.  Stackless is
CPython with a few extra features.  Translation probably works on it, but
given that Stackless has a GIL, and that rpython doesn't make use of any
Stackless APIs, it's probably just the same as translating with CPython.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered under
copyright law.  You absolutely MAY reproduce any part of it in accordance
with the copyright law of the nation you are reading this in.  Any attempt
to DENY YOU THOSE RIGHTS would be illegal without prior contractual
agreement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160909/5228deb7/attachment-0001.html>

From fijall at gmail.com  Fri Sep  9 03:49:02 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 9 Sep 2016 09:49:02 +0200
Subject: [pypy-dev] Build Pypy with different Interpreters
In-Reply-To: <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>
References: <a4f4f14e-d047-1b83-d166-5c3eba3c5e09@t-online.de>
 <CAHgd1hG5ox52HaJcHHFPbK7E+woWyHKokJUzb2V_F-97rjVjvg@mail.gmail.com>
 <31d9ec55-5c81-78d1-ac2c-979a0ac46727@t-online.de>
Message-ID: <CAK5idxTqX9BdAYeepTWZOWu0dmxm4YfswxTpnM9zCA8TJoTFGA@mail.gmail.com>

Hi Jan

The short answer is - all of those interpreters are a lot slower than
pypy. Having even relatively good parallelization (and only some steps
can be parallelized) would yield no improvements over using pure pypy
for the most examples

On Thu, Sep 8, 2016 at 2:38 PM, Jan Brohl <janbrohl at t-online.de> wrote:
> Sorry, for the typo - I was asking if it is possible to build pypy *with*
> different interpreters instead of just cpython and pypy.
>
> (using eg "ipy64" instead of "pypy" or "python" in the translation step
> described at
> http://doc.pypy.org/en/latest/build.html#run-the-translation )
>
>
> Am 08.09.2016 um 14:07 schrieb William ML Leslie:
>>
>> On 8 September 2016 at 19:40, Jan Brohl <janbrohl at t-online.de
>> <mailto:janbrohl at t-online.de>>wrote:
>>
>>
>>     Is it possible to build different interpreters like Stackless,
>>     IronPython or Jython?
>>
>>
>> That was actually the original motivation for creating pypy -
>> maintaining all those different python implementations was a lot of
>> unnecessary work.  Stackless support is enabled by default.  Support
>> for translating to CLI and the JVM was eventually dropped for lack of
>> interest.  If someone wanted to re-add that support, they could learn
>> from the mistakes that the previous implementation used.
>>
>> http://doc.pypy.org/en/latest/stackless.html
>>
>>
>>
>>
>>     If not - why?
>>
>>     If yes - is it (in theory) possible to gain a speedup on those
>>     without GIL? (Is there multithreading at all the in translation
>>     process?)
>>
>>
>> Translation can't be done concurrently at the moment.  I probably
>> should have expanded upon this in my previous email, and maybe I will;
>> there are a number of global structures, registries, and work lists that
>> would need to be refactored before the translation work could be
>> distributed.  If that's the route the pypy team go, we will consider it
>> after pypy itself supports parallelism.
>>
>> There's another route, which is to support separate compilation, and
>> then to hand off the translation of built-in modules to different
>> executors.  This is itself quite a bit of work due to some inherent
>> properties of rpython.
>>
>> --
>> William Leslie
>>
>> Notice:
>> Likely much of this email is, by the nature of copyright, covered under
>> copyright law.  You absolutely MAY reproduce any part of it in
>> accordance with the copyright law of the nation you are reading this
>> in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior
>> contractual agreement.
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From arigo at tunes.org  Sat Sep 10 05:15:15 2016
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 10 Sep 2016 11:15:15 +0200
Subject: [pypy-dev] RevDB released
Message-ID: <CAMSv6X12zmbEv7=_Q+9VYP8mM8HoXCxs7VM84O8j3ujy_HXBFQ@mail.gmail.com>

Hi all,

It is my pleasure to announce the first beta release of RevDB: a
"reverse debugger" for Python.

A reverse debugger is a debugger where you can go forward and backward
in time.  RevDB is designed to track down the annoying,
hard-to-reproduce bug in your Python program.  It is based on PyPy,
but it is useful even if you usually run your programs on CPython.

Note that Win32 is not supported so far.  As usual here, this is
Python 2.7 only, but it should not be too hard to add support for
revdb in the py3k/py3.5 branches.

https://bitbucket.org/pypy/revdb/


A bient?t,

Armin

From arigo at tunes.org  Sat Sep 17 05:02:42 2016
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 17 Sep 2016 11:02:42 +0200
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
Message-ID: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>

Hi Ronan, hi all,

Can we fix a date after which we stop needing to update pypy 3.3?  It
is a (minor) mess that, whenever I find a bug or small missing feature
in pypy 3.5, I usually try first to see if it should be done in the
py3k (3.3) branch or directly in py3.5.  In fact I would guess by now
that I have misplaced one or two such fixes.  Sorry about that.  It
would help reduce the overhead if we could all focus on py3.5.

At the start of August, Ronan mentioned the last pypy 3.3 release
being 1 or 2 months away.  Ronan, can you say what you'd still like to
do and what you'd like fixed first for the release?  I can help you
with that.

I suggest that we tentatively fix the date of October the 8th for the
release (this is just after PyCon ZA).  Then we can then focus our
South African sprint on py3.5.

About the sprint: anyone around Cape Town for the two weeks after
PyCon ZA is welcome to join.  We don't have exactly a plan so far; for
sure we will not be sprinting without some break days.


A bient?t,

Armin.

From arigo at tunes.org  Tue Sep 20 04:27:35 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 20 Sep 2016 10:27:35 +0200
Subject: [pypy-dev] Change how a pypy executable finds its
 lib-python/lib_pypy directories?
Message-ID: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>

Hi all,

Right now the "pypy" executable looks for its lib-python/lib_pypy
directories by starting from the path of the "pypy" executable and
going up.  That path is derived from the C-level argv[0], on which we
try once to call readlink() if it is a symlink.  That logic is in
pypy.module.sys.initpath.

When using cffi's embedding mode, however, the logic starts
differently: we start at the path of the "libpypy-c.so" library
instead, and then we look around in the same way.  This is because, of
course, there is no "pypy" executable in this case.

This difference breaks some packaged pypy's: it is the only thing that
prevents e.g. the Arch Linux pypy from working in embedded mode.  The
reason is that they install /opt/pypy/* like we recommend, and set a
symlink /usr/bin/pypy -> /opt/pypy/bin/pypy like we also recommend,
but they really move libpypy-c.so in /usr/lib/libpypy-c.so.  It works
fine in the regular case, but fails with the embedding mode.  I tried
to make a symlink /usr/lib/libpypy-c.so -> /opt/pypy/bin/libpypy-c.so
and embedding mode then works fine.

As an attempt to fix this more generally, we should make the two cases
more similar.  Does it make sense to only look around from the
"libpypy-c.so" location?  Finding the path of "libpypy-c.so" requires
a little bit more hackery than just reading "argv[0]", but on the
other hand it is not likely to break even if "pypy" is called
strangely (because argv[0] can in theory be any random string).  It is
code that is so far in pypy.module._cffi_backend.embedding, which
would probably move to pypy.module.sys.initpath.

This change would require minor fixes for pypy packagers---e.g. arch
linux would simply make a symlink for /usr/lib/libpypy-c.so instead of
for /usr/bin/pypy.  Makes sense?


A bient?t,

Armin.

From arigo at tunes.org  Tue Sep 20 05:14:18 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 20 Sep 2016 11:14:18 +0200
Subject: [pypy-dev] pypy_win64_support
In-Reply-To: <078AA0FFE8C7034097F90205717F504611EE6A5B@IRSMSX102.ger.corp.intel.com>
References: <078AA0FFE8C7034097F90205717F504611EC7D08@IRSMSX102.ger.corp.intel.com>
 <CAMSv6X1-0N7zk7Kk4RjZQkRxuj_fJVeXCL-uBfuhayCtBH22JA@mail.gmail.com>
 <078AA0FFE8C7034097F90205717F504611EE6A5B@IRSMSX102.ger.corp.intel.com>
Message-ID: <CAMSv6X1RXuR57WcW44aNBA43chaFhJnse4DYZksUJZ8aePx0bA@mail.gmail.com>

Hi Diana,

Answering you on the pypy-dev mailing list.  The question is about
Win64 support (http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit-translation):

On 19 September 2016 at 14:34, Popa, Diana <diana.popa at intel.com> wrote:
> First of all, I started by translating PyPy on win64 with a hacked 2.7 Python as described in the provided URL. I am encountering a problem when trying to calculate MAX_DIGITS_THAT_CAN_FIT_IN_INT = rbigint.fromint(-sys.maxint - 1).numdigits(). (...)

The URL doesn't describe what you are doing: it tells about hacking
Python 2.7, yes, but the next thing it says you should do is trying to
pass a specific subset of the tests.  There is no point in immediately
trying to translating PyPy.  But anyway, if you tried doing that, you
would hit the same problem immediately.  This is caused by the
"precision loss" I wrote about on that page.  I assume that sys.maxint
is equal to 2**63-1 in your hacked Python.  Then likely some
operations occur in C on this "long long" value that temporarily cast
the value to "long", resulting in precision loss.  You have to track
down what it is.  For example, start by writing some tests and put
them in rpython.rlib.test.test_win64:

def test_basic_arithmetic():
    def eq(x, y):
         assert type(x) is type(y) is int
         return x == y
    x = 2**50
    assert eq(x, 2**50)
    assert str(x) == "1125899906842624"
    assert str(sys.maxint) == "9223372036854775807"
    assert eq(sys.maxint, int(2**63-1))
    assert eq(x + x, 2**51)
    assert eq(x - (-x), 2**51)
    assert eq(x * 4, 2**52)
    assert eq(x | x, 2**50)
    assert eq(x >> 1, 2**49)
   etc.

...as I guess that there is code a bit everywhere that depends on
that.  Fixing such failures is a matter of tracking down where CPython
stores things temporarily inside "long".

It is not necessary to get a perfect CPython that handles "long long"
systematically, but at least the basics like above should work.
Alternatively, you could try to globally replace "long" with "long
long" and similar.


A bient?t,

Armin.

From ronan.lamy at gmail.com  Tue Sep 20 11:34:16 2016
From: ronan.lamy at gmail.com (Ronan Lamy)
Date: Tue, 20 Sep 2016 16:34:16 +0100
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
Message-ID: <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>

Le 17/09/16 ? 10:02, Armin Rigo a ?crit :
> Hi Ronan, hi all,
>
> Can we fix a date after which we stop needing to update pypy 3.3?  It
> is a (minor) mess that, whenever I find a bug or small missing feature
> in pypy 3.5, I usually try first to see if it should be done in the
> py3k (3.3) branch or directly in py3.5.  In fact I would guess by now
> that I have misplaced one or two such fixes.  Sorry about that.  It
> would help reduce the overhead if we could all focus on py3.5.

The advantage of having py3k is that regressions are much more visible 
there than on py3.5, but I agree that the overhead of having two py3 
branches is too high. We can't go on like this for much longer.

> At the start of August, Ronan mentioned the last pypy 3.3 release
> being 1 or 2 months away.  Ronan, can you say what you'd still like to
> do and what you'd like fixed first for the release?  I can help you
> with that.

For all remaining linux64 test failures, we should either fix them or 
explicitly decide not to bother (e.g. in cpyext). This mostly means 
reviewing and stabilising the buffer interface. Some issues also need to 
be fixed, like #2278 (os.stat()) and #2312 (venv).

Also, win32 doesn't seem too far from working, so we should try to fix 
it as well. Finishing the posix module would be also be nice, though the 
last missing bits seem obscure enough that we can live without.

>
> I suggest that we tentatively fix the date of October the 8th for the
> release (this is just after PyCon ZA).  Then we can then focus our
> South African sprint on py3.5.

8 October seems doable, so +1.
>
> About the sprint: anyone around Cape Town for the two weeks after
> PyCon ZA is welcome to join.  We don't have exactly a plan so far; for
> sure we will not be sprinting without some break days.
>
>
> A bient?t,
>
> Armin.
>


From hodgestar at gmail.com  Tue Sep 20 12:08:26 2016
From: hodgestar at gmail.com (Simon Cross)
Date: Tue, 20 Sep 2016 18:08:26 +0200
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
 <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
Message-ID: <CAD5NRCFH22XD9sgbhSEYCP=gM-Pi+TuykqntL-hFta+r7ThU9Q@mail.gmail.com>

I added PyPy to the list of PyConZA sprint topics --
https://za.pycon.org/news/sprints/.

From arigo at tunes.org  Tue Sep 20 12:59:43 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 20 Sep 2016 18:59:43 +0200
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <CAD5NRCFH22XD9sgbhSEYCP=gM-Pi+TuykqntL-hFta+r7ThU9Q@mail.gmail.com>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
 <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
 <CAD5NRCFH22XD9sgbhSEYCP=gM-Pi+TuykqntL-hFta+r7ThU9Q@mail.gmail.com>
Message-ID: <CAMSv6X2G8m8weVSHjWafCgg-znv3_Bsm87F5Kxbju1PDLnydpA@mail.gmail.com>

Hi Simon,

On 20 September 2016 at 18:08, Simon Cross <hodgestar at gmail.com> wrote:
> I added PyPy to the list of PyConZA sprint topics --
> https://za.pycon.org/news/sprints/.

Thanks!

Armin

From arigo at tunes.org  Tue Sep 20 13:00:41 2016
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 20 Sep 2016 19:00:41 +0200
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
 <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
Message-ID: <CAMSv6X1ppsxtE9D4AUPzxxKQ6esy+zceuWJt7U00nTqZv7XVNg@mail.gmail.com>

Hi Ronan,

On 20 September 2016 at 17:34, Ronan Lamy <ronan.lamy at gmail.com> wrote:
> For all remaining linux64 test failures, we should either fix them or
> explicitly decide not to bother (e.g. in cpyext). This mostly means
> reviewing and stabilising the buffer interface. Some issues also need to be
> fixed, like #2278 (os.stat()) and #2312 (venv).
>
> Also, win32 doesn't seem too far from working, so we should try to fix it as
> well. Finishing the posix module would be also be nice, though the last
> missing bits seem obscure enough that we can live without.

Ok!  I'll start with #2278 and then look at Windows, assuming nobody
else does it before me.


A bient?t,

Armin.

From pjenvey at underboss.org  Tue Sep 20 23:22:01 2016
From: pjenvey at underboss.org (Philip Jenvey)
Date: Tue, 20 Sep 2016 20:22:01 -0700
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <CAMSv6X1ppsxtE9D4AUPzxxKQ6esy+zceuWJt7U00nTqZv7XVNg@mail.gmail.com>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
 <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
 <CAMSv6X1ppsxtE9D4AUPzxxKQ6esy+zceuWJt7U00nTqZv7XVNg@mail.gmail.com>
Message-ID: <677DA209-2A28-407D-A285-02EC5FCCA3C1@underboss.org>

> On Sep 20, 2016, at 10:00 AM, Armin Rigo <arigo at tunes.org> wrote:
> 
> Hi Ronan,
> 
> On 20 September 2016 at 17:34, Ronan Lamy <ronan.lamy at gmail.com> wrote:
>> For all remaining linux64 test failures, we should either fix them or
>> explicitly decide not to bother (e.g. in cpyext). This mostly means
>> reviewing and stabilising the buffer interface. Some issues also need to be
>> fixed, like #2278 (os.stat()) and #2312 (venv).
>> 
>> Also, win32 doesn't seem too far from working, so we should try to fix it as
>> well. Finishing the posix module would be also be nice, though the last
>> missing bits seem obscure enough that we can live without.
> 
> Ok!  I'll start with #2278 and then look at Windows, assuming nobody
> else does it before me.

Mark Young and I have been slowly kicking py3k win32 back into shape. It?s to the point now where I thought it might translate again but py3k has been failing translation on all platforms for a couple weeks now (win32 fails in the same way as others).

Assuming it translates when that's fixed, the major issue pending for it is #2310.

?
Philip Jenvey

From arigo at tunes.org  Thu Sep 22 03:23:44 2016
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 22 Sep 2016 09:23:44 +0200
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <677DA209-2A28-407D-A285-02EC5FCCA3C1@underboss.org>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
 <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
 <CAMSv6X1ppsxtE9D4AUPzxxKQ6esy+zceuWJt7U00nTqZv7XVNg@mail.gmail.com>
 <677DA209-2A28-407D-A285-02EC5FCCA3C1@underboss.org>
Message-ID: <CAMSv6X1ZC67fvZaJ2jXtSwWcdeW03v4ryKNgpdET4y+FKhxWcw@mail.gmail.com>

Hi,

On 21 September 2016 at 05:22, Philip Jenvey <pjenvey at underboss.org> wrote:
> Mark Young and I have been slowly kicking py3k win32 back into shape. It?s to the point now where I thought it might translate again but py3k has been failing translation on all platforms for a couple weeks now (win32 fails in the same way as others).
>
> Assuming it translates when that's fixed, the major issue pending for it is #2310.

Now win32 translates.  But the list of failing tests is still
impressively long.  I have some doubts about fixing them quickly.

Just looking around randomly, I found for example that sys.maxunicode
has been changed to 1114111 even on Windows.  This is part of the
whole unicode refactoring: maxunicode is always 1114111, and you can
get unichr(1114111); then on Windows when you try to use such a
unicode string for a native FooW() function, the unicode string is
converted into a wchar_t string, using surrogates if needed.  Unsure
if it is something we can quickly hack together to make Windows happy,
or if it requires some more thinking about the whole unicode
refactoring.

As far as I can tell it's only one of the many failures.  Maybe we can
still translate and ship a Windows version of PyPy3.3, but it might be
more broken than useful to users...  Or maybe I'm just too negative.


A bient?t,

Armin.

From pjenvey at underboss.org  Thu Sep 22 22:00:17 2016
From: pjenvey at underboss.org (Philip Jenvey)
Date: Thu, 22 Sep 2016 19:00:17 -0700
Subject: [pypy-dev] PyPy 3.3? (and: informal Cape Town sprint)
In-Reply-To: <CAMSv6X1ZC67fvZaJ2jXtSwWcdeW03v4ryKNgpdET4y+FKhxWcw@mail.gmail.com>
References: <CAMSv6X3+T_tZZzW-MJV+kRuBHWURR0yCdigrogO1A=wdG-n2gQ@mail.gmail.com>
 <d469a943-0769-5ebd-d2a9-74a7e7783f11@gmail.com>
 <CAMSv6X1ppsxtE9D4AUPzxxKQ6esy+zceuWJt7U00nTqZv7XVNg@mail.gmail.com>
 <677DA209-2A28-407D-A285-02EC5FCCA3C1@underboss.org>
 <CAMSv6X1ZC67fvZaJ2jXtSwWcdeW03v4ryKNgpdET4y+FKhxWcw@mail.gmail.com>
Message-ID: <B9C9CD16-8E98-45D7-96D4-8984B4F5C292@underboss.org>

Ah, you might be right about it being too broken/too much trouble, thanks for looking.

I?m just happy to keep it translating to avoid collecting more subtle issues over time.

Other than that finishing 3.3 on other platforms/moving 3.5 along is higher priority.

--
Philip Jenvey

> On Sep 22, 2016, at 12:23 AM, Armin Rigo <arigo at tunes.org> wrote:
> 
> Now win32 translates.  But the list of failing tests is still
> impressively long.  I have some doubts about fixing them quickly.
> 
> Just looking around randomly, I found for example that sys.maxunicode
> has been changed to 1114111 even on Windows.  This is part of the
> whole unicode refactoring: maxunicode is always 1114111, and you can
> get unichr(1114111); then on Windows when you try to use such a
> unicode string for a native FooW() function, the unicode string is
> converted into a wchar_t string, using surrogates if needed.  Unsure
> if it is something we can quickly hack together to make Windows happy,
> or if it requires some more thinking about the whole unicode
> refactoring.
> 
> As far as I can tell it's only one of the many failures.  Maybe we can
> still translate and ship a Windows version of PyPy3.3, but it might be
> more broken than useful to users...  Or maybe I'm just too negative.


From arigo at tunes.org  Sat Sep 24 16:52:51 2016
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 24 Sep 2016 22:52:51 +0200
Subject: [pypy-dev] Change how a pypy executable finds its
 lib-python/lib_pypy directories?
In-Reply-To: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>
References: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>
Message-ID: <CAMSv6X0Z_xwRCeMopnS8tHJVvUbC+mb6=pCY2fRKhbqPK5411A@mail.gmail.com>

Hi all,

Now PyPy looks for lib-python/lib_pypy starting from the (real)
location of its ``libpypy-c.so``, no longer from the ``pypy``
executable.

Linux distribution packagers, take note!  At a minimum, the
``libpypy-c.so`` must really be inside the path containing
``lib-python`` and ``lib_pypy``.  Of course, you can (and likely
should) also put a symlink to it from somewhere else.

It is what you had previously to do with the ``pypy`` executable.  Now
it must be done with ``libpypy-c.so`` instead (and you no longer have
to use a symlink for the ``pypy`` executable, as long as it finds its
``libpypy-c.so``).

If, instead, you edit PyPy to change the way it is installed, then
please take a moment to check that *embedding* works correctly.  Test
case:

https://bitbucket.org/cffi/cffi/raw/default/demo/embedding.py
https://bitbucket.org/cffi/cffi/raw/default/demo/embedding_test.c


A bient?t,

Armin.

From pjenvey at underboss.org  Sat Sep 24 17:30:04 2016
From: pjenvey at underboss.org (Philip Jenvey)
Date: Sat, 24 Sep 2016 14:30:04 -0700
Subject: [pypy-dev] Change how a pypy executable finds its
 lib-python/lib_pypy directories?
In-Reply-To: <CAMSv6X0Z_xwRCeMopnS8tHJVvUbC+mb6=pCY2fRKhbqPK5411A@mail.gmail.com>
References: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>
 <CAMSv6X0Z_xwRCeMopnS8tHJVvUbC+mb6=pCY2fRKhbqPK5411A@mail.gmail.com>
Message-ID: <53108685-1EE9-4D27-A07F-0DEC40EDD471@underboss.org>

Does this have any effect on virtualenvs?

virtualenv symlinks libpypy-c.so and _pypy_init_home returns its location realpath()?d..

--
Philip Jenvey

> On Sep 24, 2016, at 1:52 PM, Armin Rigo <arigo at tunes.org> wrote:
> 
> Hi all,
> 
> Now PyPy looks for lib-python/lib_pypy starting from the (real)
> location of its ``libpypy-c.so``, no longer from the ``pypy``
> executable.
> 
> Linux distribution packagers, take note!  At a minimum, the
> ``libpypy-c.so`` must really be inside the path containing
> ``lib-python`` and ``lib_pypy``.  Of course, you can (and likely
> should) also put a symlink to it from somewhere else.
> 
> It is what you had previously to do with the ``pypy`` executable.  Now
> it must be done with ``libpypy-c.so`` instead (and you no longer have
> to use a symlink for the ``pypy`` executable, as long as it finds its
> ``libpypy-c.so``).
> 
> If, instead, you edit PyPy to change the way it is installed, then
> please take a moment to check that *embedding* works correctly.  Test
> case:
> 
> https://bitbucket.org/cffi/cffi/raw/default/demo/embedding.py
> https://bitbucket.org/cffi/cffi/raw/default/demo/embedding_test.c
> 
> 
> A bient?t,
> 
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev


From arigo at tunes.org  Sun Sep 25 03:13:05 2016
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 25 Sep 2016 09:13:05 +0200
Subject: [pypy-dev] Change how a pypy executable finds its
 lib-python/lib_pypy directories?
In-Reply-To: <53108685-1EE9-4D27-A07F-0DEC40EDD471@underboss.org>
References: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>
 <CAMSv6X0Z_xwRCeMopnS8tHJVvUbC+mb6=pCY2fRKhbqPK5411A@mail.gmail.com>
 <53108685-1EE9-4D27-A07F-0DEC40EDD471@underboss.org>
Message-ID: <CAMSv6X03fWOFFLOBCnSFCNb+9Cp5ymGr=dzeFcFpLjC7YHSArw@mail.gmail.com>

Hi Philip,

On 24 September 2016 at 23:30, Philip Jenvey <pjenvey at underboss.org> wrote:
> Does this have any effect on virtualenvs?
>
> virtualenv symlinks libpypy-c.so and _pypy_init_home returns its location realpath()?d..

Well spotted.  More thinking needed.

Armin

From arigo at tunes.org  Sun Sep 25 04:16:52 2016
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 25 Sep 2016 10:16:52 +0200
Subject: [pypy-dev] Change how a pypy executable finds its
 lib-python/lib_pypy directories?
In-Reply-To: <CAMSv6X03fWOFFLOBCnSFCNb+9Cp5ymGr=dzeFcFpLjC7YHSArw@mail.gmail.com>
References: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>
 <CAMSv6X0Z_xwRCeMopnS8tHJVvUbC+mb6=pCY2fRKhbqPK5411A@mail.gmail.com>
 <53108685-1EE9-4D27-A07F-0DEC40EDD471@underboss.org>
 <CAMSv6X03fWOFFLOBCnSFCNb+9Cp5ymGr=dzeFcFpLjC7YHSArw@mail.gmail.com>
Message-ID: <CAMSv6X0kA1StfRGCGRgC8=NvmxNbXCiiQadV3zPPuhnvw1ti0w@mail.gmail.com>

Hi again,

On 25 September 2016 at 09:13, Armin Rigo <arigo at tunes.org> wrote:
> On 24 September 2016 at 23:30, Philip Jenvey <pjenvey at underboss.org> wrote:
>> Does this have any effect on virtualenvs?
>>
>> virtualenv symlinks libpypy-c.so and _pypy_init_home returns its location realpath()?d..

How about looking first from the place of the symlink itself, and if
not found, we dereference the symlink and look again?


A bient?t,

Armin.

From arigo at tunes.org  Mon Sep 26 05:54:28 2016
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 26 Sep 2016 11:54:28 +0200
Subject: [pypy-dev] Change how a pypy executable finds its
 lib-python/lib_pypy directories?
In-Reply-To: <CAMSv6X0kA1StfRGCGRgC8=NvmxNbXCiiQadV3zPPuhnvw1ti0w@mail.gmail.com>
References: <CAMSv6X2umXhv1z3PbxPYTyOdG7zaYJ+AhBN_XLCeb66HU-i0kA@mail.gmail.com>
 <CAMSv6X0Z_xwRCeMopnS8tHJVvUbC+mb6=pCY2fRKhbqPK5411A@mail.gmail.com>
 <53108685-1EE9-4D27-A07F-0DEC40EDD471@underboss.org>
 <CAMSv6X03fWOFFLOBCnSFCNb+9Cp5ymGr=dzeFcFpLjC7YHSArw@mail.gmail.com>
 <CAMSv6X0kA1StfRGCGRgC8=NvmxNbXCiiQadV3zPPuhnvw1ti0w@mail.gmail.com>
Message-ID: <CAMSv6X27+eT+Zbmad0dT15Yqf4iuZa1ppt1QHduoRiRpE0_AdQ@mail.gmail.com>

Hi,

On 25 September 2016 at 10:16, Armin Rigo <arigo at tunes.org> wrote:
> How about looking first from the place of the symlink itself, and if
> not found, we dereference the symlink and look again?

That can't work, because there is no way to know the path of the
symlink to libpypy-c.so.  We can only learn the dereferenced path,
using dladdr().

I've partly reverted my check-in: now we look first based on the pypy
executable's real location, like before; and only if that fails, we
look based on the libpypy-c.so's real location.  Like before, we never
look based on where a symlink is.

That means it should be fully backward compatible, but in addition it
also works if the symlink is on the libpypy-c.so instead of the pypy
executable.  We should still try to convince a few distributions to
use this new approach, in order to fix embedding there.


A bient?t,

Armin.

From tuom.larsen at gmail.com  Mon Sep 26 16:57:49 2016
From: tuom.larsen at gmail.com (Tuom Larsen)
Date: Mon, 26 Sep 2016 22:57:49 +0200
Subject: [pypy-dev] Sorting structs
Message-ID: <CALkqZMcaEjzn5TuybD=txwWwVYASRF66JQoib8DXVFQaZ71ZxQ@mail.gmail.com>

Dear list!

I stumbled upon a problem and I was wondering if someone would by so
kind and explain to me what is going on.

The problem is sorting 2 000 000 points by `x` coordinate:

    from random import random
    from time import time

    class point(object):
        def __init__(self, x, y):
            self.x, self.y = x, y

    data = [point(random(), random()) for i in range(2000000)]

    t = time()
    data.sort(key=lambda p:p.x)
    print time() - t

on my machine in runs 8.74s under PyPy 5.4.1 on MacOS. I then try to
sort the points in JavaScript:

    var data = [];
    for (var i=0; i<2000000; i++) {
        data.push({x:Math.random(), y:Math.random()});
    }

    console.time('sorting');
    data.sort(function(a, b) { return a.x - b.x; });
    console.timeEnd('sorting');

and it runs in 3.09s under V8 5.3.

I was just wondering, why is it nearly 3x slower under PyPy than it is
under V8? Is there any way I could make the code run faster?

Thank you in advance!

From cfbolz at gmx.de  Tue Sep 27 13:19:21 2016
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 27 Sep 2016 19:19:21 +0200
Subject: [pypy-dev] improve error message when missing 'self' in method
 definition
Message-ID: <8453e56c-5971-9b73-dea0-e8a75f7d9d85@gmx.de>

Hi all,

I read this paper today about common mistakes that Python beginners
make:

https://www.researchgate.net/publication/307088989_Some_Trouble_with_Transparency_An_Analysis_of_Student_Errors_with_Object-oriented_Python

The most common one by far is forgetting the "self" parameter in the
method definition (which also still happens to me regularly). The error
message is not particularly enlightening, if you don't quite understand
the explicit self in Python.


So I wonder whether we should print a better error message, something
like this:

$ cat m.py
class A(object):
    def f(x):
        return self.x
A().f(1)

$ pypy m.py
Traceback (application-level):
  File "m.py", line 4 in <module>
    A().f(1)
TypeError: f() takes exactly 1 argument (2 given). Did you forget 'self'
in the function definition?


It's a bit the question how clever we would like this to be to reduce
false positives, see the attached patch for a very simple approach.

Anyone have opinions?

Cheers,

Carl Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: selfmsg.patch
Type: text/x-patch
Size: 3960 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160927/fb74f0f0/attachment.bin>

From fijall at gmail.com  Tue Sep 27 13:53:49 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 27 Sep 2016 19:53:49 +0200
Subject: [pypy-dev] improve error message when missing 'self' in method
 definition
In-Reply-To: <8453e56c-5971-9b73-dea0-e8a75f7d9d85@gmx.de>
References: <8453e56c-5971-9b73-dea0-e8a75f7d9d85@gmx.de>
Message-ID: <CAK5idxQKC+yEVtzhYJV3rWeCO7bzjWvG6U4jLy4LmXe-6OgCCQ@mail.gmail.com>

I'm +1

On Tue, Sep 27, 2016 at 7:19 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Hi all,
>
> I read this paper today about common mistakes that Python beginners
> make:
>
> https://www.researchgate.net/publication/307088989_Some_Trouble_with_Transparency_An_Analysis_of_Student_Errors_with_Object-oriented_Python
>
> The most common one by far is forgetting the "self" parameter in the
> method definition (which also still happens to me regularly). The error
> message is not particularly enlightening, if you don't quite understand
> the explicit self in Python.
>
>
> So I wonder whether we should print a better error message, something
> like this:
>
> $ cat m.py
> class A(object):
>     def f(x):
>         return self.x
> A().f(1)
>
> $ pypy m.py
> Traceback (application-level):
>   File "m.py", line 4 in <module>
>     A().f(1)
> TypeError: f() takes exactly 1 argument (2 given). Did you forget 'self'
> in the function definition?
>
>
> It's a bit the question how clever we would like this to be to reduce
> false positives, see the attached patch for a very simple approach.
>
> Anyone have opinions?
>
> Cheers,
>
> Carl Friedrich
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From rymg19 at gmail.com  Tue Sep 27 14:33:08 2016
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Tue, 27 Sep 2016 13:33:08 -0500
Subject: [pypy-dev] improve error message when missing 'self' in method
 definition
In-Reply-To: <8453e56c-5971-9b73-dea0-e8a75f7d9d85@gmx.de>
References: <8453e56c-5971-9b73-dea0-e8a75f7d9d85@gmx.de>
Message-ID: <CAO41-mM19xhnZXFkBe6kh0BOCnKHD35c9yA2uuBsJOpC0Mhb8g@mail.gmail.com>

Have you considered bringing this up on python-ideas, too?

On Tue, Sep 27, 2016 at 12:19 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:

> Hi all,
>
> I read this paper today about common mistakes that Python beginners
> make:
>
> https://www.researchgate.net/publication/307088989_Some_
> Trouble_with_Transparency_An_Analysis_of_Student_Errors_
> with_Object-oriented_Python
>
> The most common one by far is forgetting the "self" parameter in the
> method definition (which also still happens to me regularly). The error
> message is not particularly enlightening, if you don't quite understand
> the explicit self in Python.
>
>
> So I wonder whether we should print a better error message, something
> like this:
>
> $ cat m.py
> class A(object):
>     def f(x):
>         return self.x
> A().f(1)
>
> $ pypy m.py
> Traceback (application-level):
>   File "m.py", line 4 in <module>
>     A().f(1)
> TypeError: f() takes exactly 1 argument (2 given). Did you forget 'self'
> in the function definition?
>
>
> It's a bit the question how clever we would like this to be to reduce
> false positives, see the attached patch for a very simple approach.
>
> Anyone have opinions?
>
> Cheers,
>
> Carl Friedrich
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20160927/58650357/attachment.html>

From florin.papa at intel.com  Tue Sep 27 17:01:52 2016
From: florin.papa at intel.com (Papa, Florin)
Date: Tue, 27 Sep 2016 21:01:52 +0000
Subject: [pypy-dev] NumPy or NumPyPy
Message-ID: <3A375A669FBEFF45B6B60E689636EDCA09C59FB6@IRSMSX101.ger.corp.intel.com>

Hello,

I read this announcement [1] saying that "over 99% of the upstream numpy test suite" is passed. Is this when using pypy with the upstream numpy (thanks to the incremental improvements brought to cpyext) or is it when using pypy with numpypy?

I also found this link [2], tracking numpypy status. Is numpypy still maintained or does this buildbot track the regression tests for upstream numpy in pypy (using cpyext)?

[1] https://morepypy.blogspot.com/2016/08/pypy2-v54-released-incremental.html
[2] http://buildbot.pypy.org/numpy-status/latest.html

Thank you,
Florin




From rymg19 at gmail.com  Tue Sep 27 17:15:35 2016
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Tue, 27 Sep 2016 16:15:35 -0500
Subject: [pypy-dev] NumPy or NumPyPy
In-Reply-To: <3A375A669FBEFF45B6B60E689636EDCA09C59FB6@IRSMSX101.ger.corp.intel.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C59FB6@IRSMSX101.ger.corp.intel.com>
Message-ID: <CAO41-mOhCm7GkDVevdZJUB+nTu9EbW+XcRnLmkEZ+=rsCkSNhQ@mail.gmail.com>

IIRC referring to numpy w/ cpyext.

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/

On Sep 27, 2016 4:02 PM, "Papa, Florin" <florin.papa at intel.com> wrote:

> Hello,
>
> I read this announcement [1] saying that "over 99% of the upstream numpy
> test suite" is passed. Is this when using pypy with the upstream numpy
> (thanks to the incremental improvements brought to cpyext) or is it when
> using pypy with numpypy?
>
> I also found this link [2], tracking numpypy status. Is numpypy still
> maintained or does this buildbot track the regression tests for upstream
> numpy in pypy (using cpyext)?
>
> [1] https://morepypy.blogspot.com/2016/08/pypy2-v54-released-
> incremental.html
> [2] http://buildbot.pypy.org/numpy-status/latest.html
>
> Thank you,
> Florin
>
>
>
> _______________________________________________
> 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/20160927/af67c0fd/attachment.html>

From fijall at gmail.com  Wed Sep 28 02:17:02 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 28 Sep 2016 08:17:02 +0200
Subject: [pypy-dev] improve error message when missing 'self' in method
 definition
In-Reply-To: <CAO41-mM19xhnZXFkBe6kh0BOCnKHD35c9yA2uuBsJOpC0Mhb8g@mail.gmail.com>
References: <8453e56c-5971-9b73-dea0-e8a75f7d9d85@gmx.de>
 <CAO41-mM19xhnZXFkBe6kh0BOCnKHD35c9yA2uuBsJOpC0Mhb8g@mail.gmail.com>
Message-ID: <CAK5idxTqRJgAXY71UQTfm4S2Avqy=6A0edh=7yZ1bUv9WkvJKA@mail.gmail.com>

On Tue, Sep 27, 2016 at 8:33 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> Have you considered bringing this up on python-ideas, too?

python-idea is generally quite a hostile place. That said, if you
think it's worth your effort to submit it there, feel free to do so,
just the core pypy devs feel their time is better spent elsewhere than
arguing on python-ideas

>
> On Tue, Sep 27, 2016 at 12:19 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>>
>> Hi all,
>>
>> I read this paper today about common mistakes that Python beginners
>> make:
>>
>>
>> https://www.researchgate.net/publication/307088989_Some_Trouble_with_Transparency_An_Analysis_of_Student_Errors_with_Object-oriented_Python
>>
>> The most common one by far is forgetting the "self" parameter in the
>> method definition (which also still happens to me regularly). The error
>> message is not particularly enlightening, if you don't quite understand
>> the explicit self in Python.
>>
>>
>> So I wonder whether we should print a better error message, something
>> like this:
>>
>> $ cat m.py
>> class A(object):
>>     def f(x):
>>         return self.x
>> A().f(1)
>>
>> $ pypy m.py
>> Traceback (application-level):
>>   File "m.py", line 4 in <module>
>>     A().f(1)
>> TypeError: f() takes exactly 1 argument (2 given). Did you forget 'self'
>> in the function definition?
>>
>>
>> It's a bit the question how clever we would like this to be to reduce
>> false positives, see the attached patch for a very simple approach.
>>
>> Anyone have opinions?
>>
>> Cheers,
>>
>> Carl Friedrich
>>
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something?s wrong.
> http://kirbyfan64.github.io/
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Wed Sep 28 02:18:02 2016
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 28 Sep 2016 08:18:02 +0200
Subject: [pypy-dev] NumPy or NumPyPy
In-Reply-To: <3A375A669FBEFF45B6B60E689636EDCA09C59FB6@IRSMSX101.ger.corp.intel.com>
References: <3A375A669FBEFF45B6B60E689636EDCA09C59FB6@IRSMSX101.ger.corp.intel.com>
Message-ID: <CAK5idxSgd-+SpZMDFGftoq0SJJyWR8gwGk1HE0VmyLzUQKPGrQ@mail.gmail.com>

Hi

We're maintaining both and we are planning into merging (in some point
in the future) the good parts of numpypy (speed of array access) with
the good parts of c numpy (compatibility)

On Tue, Sep 27, 2016 at 11:01 PM, Papa, Florin <florin.papa at intel.com> wrote:
> Hello,
>
> I read this announcement [1] saying that "over 99% of the upstream numpy test suite" is passed. Is this when using pypy with the upstream numpy (thanks to the incremental improvements brought to cpyext) or is it when using pypy with numpypy?
>
> I also found this link [2], tracking numpypy status. Is numpypy still maintained or does this buildbot track the regression tests for upstream numpy in pypy (using cpyext)?
>
> [1] https://morepypy.blogspot.com/2016/08/pypy2-v54-released-incremental.html
> [2] http://buildbot.pypy.org/numpy-status/latest.html
>
> Thank you,
> Florin
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev