From matti.picus at gmail.com  Wed Dec 11 03:36:22 2019
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 11 Dec 2019 10:36:22 +0200
Subject: [pypy-dev] Version 7.3.0rc1 tarballs are availabe for testing
Message-ID: <1e0a09c2-8b61-d3d0-bcc9-b880d40fa903@gmail.com>

I uploaded tarballs of the 7.3.0rc1 release to 
https://bitbucket.org/pypy/pypy/downloads/

The release note is here http://doc.pypy.org/en/latest/release-v7.3.0.html


We have changed the SOABI and the linux tarballs are now "portable", 
mimicking the portable-pypy build system, based on centos6.

Please try them out on your platform, pip install a c-extension or cffi 
module to make sure everything works as expected.


Comments on the release note are welcome as well.


Thanks,

Matti


pypy2.7-7.3.0 sha256::

bf8df42c43e43af558f5c6a59c76e4b01cee718999d28d0820d17ba66f21125d 
pypy2.7-v7.3.0rc1-aarch64.tar.bz2
e8c08c5e6303d12656b3860a54788a581325202db1d9526477be27344c40d106 
pypy2.7-v7.3.0rc1-linux32.tar.bz2
7b42389279b2ed00c2e9a66c9a2eb4fefb4ce62929da0d73880f041f37d37f17 
pypy2.7-v7.3.0rc1-linux64.tar.bz2
326344ec8c08bec1f968ced750ebecb95a1823314751b54a592eef7b0c8fa8aa 
pypy2.7-v7.3.0rc1-osx64.tar.bz2
a1a9f37a3fdea1a10f619107f5254c4e1712badac338b4882c2da9739842d746 
pypy2.7-v7.3.0rc1-s390x.tar.bz2
5b3d92e591bfd74693db87119da2b77ba35c06947bd098afd293ec846b35bafb 
pypy2.7-v7.3.0rc1-src.tar.bz2
51d8b0dee35c593072ac63dafcde3bf02deb0f0fe3c40585dc29a2d520882197 
pypy2.7-v7.3.0rc1-src.zip
6d1f9766bca3445e7275494be7b72d196fd6f9de0c2bde0d509cfaad930bee67 
pypy2.7-v7.3.0rc1-win32.zip

pypy3.6-7.3.0 sha256::

dc7c2a34920e13a2968f822291d1a85faec99f7c8708da15828ae3f4b142b284 
pypy3.6-v7.3.0rc1-aarch64.tar.bz2
16d7ee8b6e031863fd958024d9d38dcb114484d4673db5f0ada60bedb5c2ed2c 
pypy3.6-v7.3.0rc1-linux32.tar.bz2
4b4d63d60746a8812a5a6524b5242425a41dbe2bcdb59435893d1212048a1f18 
pypy3.6-v7.3.0rc1-linux64.tar.bz2
3ae4c7fa6c66c402d71f4e720969b0e89cf7550745cb585981ad5be6385758ca 
pypy3.6-v7.3.0rc1-osx64.tar.bz2
df80be7d215aa967d40d26c59b825fff2c5ff2bd1764e1300a4dd15d5c1b482f 
pypy3.6-v7.3.0rc1-s390x.tar.bz2
f386f658b53c5010a93b722d87a3e536fd61bff8da0a401515f8640082443530 
pypy3.6-v7.3.0rc1-src.tar.bz2
0943983740ed0ed29c5097c5a95b1d269357377477d7e2a10e597c728a25485b 
pypy3.6-v7.3.0rc1-src.zip
a099a46c5efca7927cf304dd36b98e9c61b9da7657ce555275bb1b9e33f7a095 
pypy3.6-v7.3.0rc1-win32.zip



From rb at dustyfeet.com  Mon Dec 16 05:24:33 2019
From: rb at dustyfeet.com (Rocky Bernstein)
Date: Mon, 16 Dec 2019 05:24:33 -0500
Subject: [pypy-dev] pypy specific code flags DONT_IMPLY_DEDENT and
 SOURCE_IS_UTF8
Message-ID: <CANCp2gavnFyOejw9Y5NZxbgEs46XATDEUg0TG9KwyHsibuRPcw@mail.gmail.com>

Hi -

I have a cross-version Python bytecode disassembler xdis (
https://pypi.org/project/xdis/) and I notice that flags 0x0100 and 0x0200
(DONT_IMPLY_DEDENT and SOURCE_IS_UTF8 respectively) conflict in Pypy 3.6
with Python 3.6's  ITERABLE_COROUTINE and ASYNC_GENERATOR.

However in pypy3.6-7.2.0, inspect.CO_ITERABLE_COROUTINE and
inspect.CO_ASYNC_GENERATOR are defined to their Python 3.6 values.

So what should a disassembler do which it sees 0x0100 as a flag in a code
object? Does that reflect the PyPy meaning or the 3.6 meaning? And how can
one tell if the code has the other property?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20191216/515b2c7c/attachment.html>

From armin.rigo at gmail.com  Mon Dec 16 05:32:50 2019
From: armin.rigo at gmail.com (Armin Rigo)
Date: Mon, 16 Dec 2019 11:32:50 +0100
Subject: [pypy-dev] pypy specific code flags DONT_IMPLY_DEDENT and
 SOURCE_IS_UTF8
In-Reply-To: <CANCp2gavnFyOejw9Y5NZxbgEs46XATDEUg0TG9KwyHsibuRPcw@mail.gmail.com>
References: <CANCp2gavnFyOejw9Y5NZxbgEs46XATDEUg0TG9KwyHsibuRPcw@mail.gmail.com>
Message-ID: <CAMSv6X3CnEnuugHd69XjN3aQuLmOaLBY=YyqopmX0VPx=N+NMQ@mail.gmail.com>

Hi,

On Mon, 16 Dec 2019 at 11:24, Rocky Bernstein <rb at dustyfeet.com> wrote:
> I have a cross-version Python bytecode disassembler xdis (https://pypi.org/project/xdis/) and I notice that flags 0x0100 and 0x0200 (DONT_IMPLY_DEDENT and SOURCE_IS_UTF8 respectively) conflict in Pypy 3.6 with Python 3.6's  ITERABLE_COROUTINE and ASYNC_GENERATOR.

Looking in the CPython 3.6 source code, I see that
PyCF_DONT_IMPLY_DEDENT = 0x0200 as well there, even though
``inspect.CO_ASYNC_GENERATOR`` is also 0x0200.  The same with
PyCF_SOURCE_IS_UTF8 = 0x0100 and ``inspect.CO_ITERABLE_COROUTINE``.
So the conflict you're talking about seems to exist in CPython 3.6
too.

Can you give us a concrete example of code where CPython 3.6 differs
from PyPy 3.6?


A bient?t,

Armin.

From rb at dustyfeet.com  Mon Dec 16 05:57:19 2019
From: rb at dustyfeet.com (Rocky Bernstein)
Date: Mon, 16 Dec 2019 05:57:19 -0500
Subject: [pypy-dev] pypy specific code flags DONT_IMPLY_DEDENT and
 SOURCE_IS_UTF8
In-Reply-To: <CAMSv6X3CnEnuugHd69XjN3aQuLmOaLBY=YyqopmX0VPx=N+NMQ@mail.gmail.com>
References: <CANCp2gavnFyOejw9Y5NZxbgEs46XATDEUg0TG9KwyHsibuRPcw@mail.gmail.com>
 <CAMSv6X3CnEnuugHd69XjN3aQuLmOaLBY=YyqopmX0VPx=N+NMQ@mail.gmail.com>
Message-ID: <CANCp2gaxJ4RA5f8_0fkxb-+zCnRNiVpUWKAp5esqRYKTxE8UAw@mail.gmail.com>

I did a little test, and for this program:

# from 3.7 test_asyncgen.py
def test_async_gen_iteration_01(self):
    async def gen():
        await awaitable()
        a = yield 123

the 3.6 ASYNC_GENERATOR flag  is added in the code object created for
"gen()" as 3.6 does. So I infer that flag 0x200  in a code object doesn't
imply the PYPY_DONT_IMPLY_DEDENT property. Does that mean that in 3.6
PYPY_DON'T_IMPLY_DEDENT flag will *never *appear in a code object? Or just
for 3.6 and above or for all Pypy versions?

I don't want to try guessing what the principle being used is looking at
all versions of Pypy across all the pypy-specific flags listed
in pypy/interpreter/astcompiler/consts.py if there is a principle being
followed and someone can just tell me what it is or point to a document
that describes what's up here.


On Mon, Dec 16, 2019 at 5:33 AM Armin Rigo <armin.rigo at gmail.com> wrote:

> Hi,
>
> On Mon, 16 Dec 2019 at 11:24, Rocky Bernstein <rb at dustyfeet.com> wrote:
> > I have a cross-version Python bytecode disassembler xdis (
> https://pypi.org/project/xdis/) and I notice that flags 0x0100 and 0x0200
> (DONT_IMPLY_DEDENT and SOURCE_IS_UTF8 respectively) conflict in Pypy 3.6
> with Python 3.6's  ITERABLE_COROUTINE and ASYNC_GENERATOR.
>
> Looking in the CPython 3.6 source code, I see that
> PyCF_DONT_IMPLY_DEDENT = 0x0200 as well there, even though
> ``inspect.CO_ASYNC_GENERATOR`` is also 0x0200.  The same with
> PyCF_SOURCE_IS_UTF8 = 0x0100 and ``inspect.CO_ITERABLE_COROUTINE``.
> So the conflict you're talking about seems to exist in CPython 3.6
> too.
>
> Can you give us a concrete example of code where CPython 3.6 differs
> from PyPy 3.6?


CPython 3.6 bytecode differs from PyPy 3.6 bytecode and so far as I know it
CPython bytecode version x.y differs from Pypy  version x.y Otherwise I
wouldn't have to go through the extra effort to try to add code to make
Pypy disassembly and decompilation possible in a cross-version way. I have
for example that there are opcodes FORMAT_VALUE, BUILD_STRING and
JUMP_IF_NOT_DEBUG for example in Pypy3.6 that are not in CPython (among I
think other opcodes).

But again I'd prefer not to guess this kind of thing if it is documented
somewhere or someone who knows this already can just let me know.




>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20191216/b794a2a4/attachment.html>

From armin.rigo at gmail.com  Mon Dec 16 06:05:15 2019
From: armin.rigo at gmail.com (Armin Rigo)
Date: Mon, 16 Dec 2019 12:05:15 +0100
Subject: [pypy-dev] pypy specific code flags DONT_IMPLY_DEDENT and
 SOURCE_IS_UTF8
In-Reply-To: <CANCp2gaxJ4RA5f8_0fkxb-+zCnRNiVpUWKAp5esqRYKTxE8UAw@mail.gmail.com>
References: <CANCp2gavnFyOejw9Y5NZxbgEs46XATDEUg0TG9KwyHsibuRPcw@mail.gmail.com>
 <CAMSv6X3CnEnuugHd69XjN3aQuLmOaLBY=YyqopmX0VPx=N+NMQ@mail.gmail.com>
 <CANCp2gaxJ4RA5f8_0fkxb-+zCnRNiVpUWKAp5esqRYKTxE8UAw@mail.gmail.com>
Message-ID: <CAMSv6X3XbC58G8xHBFxWGtUeATOesWaN=ewfv8MzkCHMTgwZfA@mail.gmail.com>

Hi Rocky,

On Mon, 16 Dec 2019 at 11:57, Rocky Bernstein <rb at dustyfeet.com> wrote:
>
> I did a little test, and for this program:
>
> # from 3.7 test_asyncgen.py
> def test_async_gen_iteration_01(self):
>     async def gen():
>         await awaitable()
>         a = yield 123
>
> the 3.6 ASYNC_GENERATOR flag  is added in the code object created for "gen()" as 3.6 does. So I infer that flag 0x200  in a code object doesn't imply the PYPY_DONT_IMPLY_DEDENT property. Does that mean that in 3.6 PYPY_DON'T_IMPLY_DEDENT flag will never appear in a code object? Or just for 3.6 and above or for all Pypy versions?
>
> I don't want to try guessing what the principle being used is looking at all versions of Pypy across all the pypy-specific flags listed in pypy/interpreter/astcompiler/consts.py if there is a principle being followed and someone can just tell me what it is or point to a document that describes what's up here.

I could probably dig the answer, but the general rule is that PyPy
should do the same thing as CPython.  These two PyCF_XXX flags are
passed as arguments to compile(), and should never end up inside the
co_flags object; the CO_XXX flags are what ends up there.

> On Mon, Dec 16, 2019 at 5:33 AM Armin Rigo <armin.rigo at gmail.com> wrote:
>> Can you give us a concrete example of code where CPython 3.6 differs
>> from PyPy 3.6?
>
>
> CPython 3.6 bytecode differs from PyPy 3.6 bytecode and so far as I know it CPython bytecode version x.y differs from Pypy  version x.y Otherwise I wouldn't have to go through the extra effort to try to add code to make Pypy disassembly and decompilation possible in a cross-version way. I have for example that there are opcodes FORMAT_VALUE, BUILD_STRING and JUMP_IF_NOT_DEBUG for example in Pypy3.6 that are not in CPython (among I think other opcodes).
>
> But again I'd prefer not to guess this kind of thing if it is documented somewhere or someone who knows this already can just let me know.

I meant, an example where the flags that are produced are different.
It's entirely possible that there is a problem somewhere, e.g. we
might stick the wrong kind of flags inside co_flags.  If you're asking
this question here in the first place, then maybe you already have
such an example?  If not, then you can assume that there is no
difference as far as the flags are concerned; the only difference is
that PyPy has got a very small number of extra opcodes.  (Note that
this includes JUMP_IF_NOT_DEBUG, but not FORMAT_VALUE and
BUILD_STRING, which are from CPython.)


A bient?t,

Armin.

From rb at dustyfeet.com  Mon Dec 16 06:09:58 2019
From: rb at dustyfeet.com (Rocky Bernstein)
Date: Mon, 16 Dec 2019 06:09:58 -0500
Subject: [pypy-dev] pypy specific code flags DONT_IMPLY_DEDENT and
 SOURCE_IS_UTF8
In-Reply-To: <CAMSv6X3XbC58G8xHBFxWGtUeATOesWaN=ewfv8MzkCHMTgwZfA@mail.gmail.com>
References: <CANCp2gavnFyOejw9Y5NZxbgEs46XATDEUg0TG9KwyHsibuRPcw@mail.gmail.com>
 <CAMSv6X3CnEnuugHd69XjN3aQuLmOaLBY=YyqopmX0VPx=N+NMQ@mail.gmail.com>
 <CANCp2gaxJ4RA5f8_0fkxb-+zCnRNiVpUWKAp5esqRYKTxE8UAw@mail.gmail.com>
 <CAMSv6X3XbC58G8xHBFxWGtUeATOesWaN=ewfv8MzkCHMTgwZfA@mail.gmail.com>
Message-ID: <CANCp2gYDyaD0Vm59mMYUz=Mh0vB4hJchdzjp6yM-9PWaM3X-nA@mail.gmail.com>

Thanks - got it. Many thanks for the clarification.

I reread and missed the part where you mentioned that those two flags are
conflicts in CPython as well. I am sorry for my confusion there. (I'll ask
CPython folks what's up if there is need).



On Mon, Dec 16, 2019 at 6:05 AM Armin Rigo <armin.rigo at gmail.com> wrote:

> Hi Rocky,
>
> On Mon, 16 Dec 2019 at 11:57, Rocky Bernstein <rb at dustyfeet.com> wrote:
> >
> > I did a little test, and for this program:
> >
> > # from 3.7 test_asyncgen.py
> > def test_async_gen_iteration_01(self):
> >     async def gen():
> >         await awaitable()
> >         a = yield 123
> >
> > the 3.6 ASYNC_GENERATOR flag  is added in the code object created for
> "gen()" as 3.6 does. So I infer that flag 0x200  in a code object doesn't
> imply the PYPY_DONT_IMPLY_DEDENT property. Does that mean that in 3.6
> PYPY_DON'T_IMPLY_DEDENT flag will never appear in a code object? Or just
> for 3.6 and above or for all Pypy versions?
> >
> > I don't want to try guessing what the principle being used is looking at
> all versions of Pypy across all the pypy-specific flags listed in
> pypy/interpreter/astcompiler/consts.py if there is a principle being
> followed and someone can just tell me what it is or point to a document
> that describes what's up here.
>
> I could probably dig the answer, but the general rule is that PyPy
> should do the same thing as CPython.  These two PyCF_XXX flags are
> passed as arguments to compile(), and should never end up inside the
> co_flags object; the CO_XXX flags are what ends up there.
>
> > On Mon, Dec 16, 2019 at 5:33 AM Armin Rigo <armin.rigo at gmail.com> wrote:
> >> Can you give us a concrete example of code where CPython 3.6 differs
> >> from PyPy 3.6?
> >
> >
> > CPython 3.6 bytecode differs from PyPy 3.6 bytecode and so far as I know
> it CPython bytecode version x.y differs from Pypy  version x.y Otherwise I
> wouldn't have to go through the extra effort to try to add code to make
> Pypy disassembly and decompilation possible in a cross-version way. I have
> for example that there are opcodes FORMAT_VALUE, BUILD_STRING and
> JUMP_IF_NOT_DEBUG for example in Pypy3.6 that are not in CPython (among I
> think other opcodes).
> >
> > But again I'd prefer not to guess this kind of thing if it is documented
> somewhere or someone who knows this already can just let me know.
>
> I meant, an example where the flags that are produced are different.
> It's entirely possible that there is a problem somewhere, e.g. we
> might stick the wrong kind of flags inside co_flags.  If you're asking
> this question here in the first place, then maybe you already have
> such an example?  If not, then you can assume that there is no
> difference as far as the flags are concerned; the only difference is
> that PyPy has got a very small number of extra opcodes.  (Note that
> this includes JUMP_IF_NOT_DEBUG, but not FORMAT_VALUE and
> BUILD_STRING, which are from CPython.)
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20191216/11a4e83d/attachment-0001.html>

From matti.picus at gmail.com  Sat Dec 21 16:09:28 2019
From: matti.picus at gmail.com (Matti Picus)
Date: Sat, 21 Dec 2019 23:09:28 +0200
Subject: [pypy-dev] Version 7.3.0rc3 tarballs are availabe for testing
Message-ID: <a3cb8707-ce63-5e27-6c2d-e269e2311d21@gmail.com>

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

From matti.picus at gmail.com  Tue Dec 31 11:20:01 2019
From: matti.picus at gmail.com (Matti Picus)
Date: Tue, 31 Dec 2019 18:20:01 +0200
Subject: [pypy-dev] Help with a revamped ww.pypy.org web site
Message-ID: <09ed5fce-8888-860a-5d53-75c6b8b8bd0a@gmail.com>

In the nikola branch of pypy.org 
https://bitbucket.org/pypy/pypy.org/src/nikola/ I reworked the website 
content and layout reusing the work from 
https://github.com/frsdun/pypy-website. I would like to deploy it soon, 
as I think it is an improvement. You can try it out by checking out the 
branch, then running "make auto" which will


- build a virtualenv

- pip install nikola and other packages into the virtualenv

- convert the rst sources into html in teh public directory

- start a server on 0.0.0.0 (be careful if you don't want to open a 
socket to the world, use "make build", then run "venv_nikola/bin/nikola 
serve")

- connect with a browser: try your computer, tablet, or phone


Comments, criticisms, and especially pull requests are welcome. I am not 
a front-end designer.


Still to do:

- import the blog to move away from morepypy.blogger.com and self-host 
static pages

- import the comments too


Matti


P.S. I have also started making the benchmarks run at speed.pypy.org 
work on python3. Help there is welcome as well.