Mailman 3 December 2019 - pypy-dev

PyPy Winter Sprint + cpyext
by Stefan Beyer Dec. 20, 2022

Dec. 20, 2022

Hey everyone! Those of you who attended or followed one of the last two winter sprints in Leysin might know me, the others probably won't. I'm (still) a Master's student writing my thesis on PyPy's current issue with cross-heap cycles when using cpyext. The main point is, that they are not collected and stay around as floating garbage, even if they are not reachable any more. Correct me if I'm wrong, but I didn't notice anyone else working on that topic (and/or committing something) since I've picked it up two years ago (yeah, I know, that long ago...). I saw that you would be working on "cpyext performance and completeness" during the current winter sprint this week and thought that this might also concern my thesis. So I thought I'll give you an update. I recently pushed my current (non-optimized, breaking-some-tests, but more or less working) implementation of the "CPython-style" GC-extension for cpyext. It is still in an early stage and not all cases (legacy and non-legacy-finalizers, weakrefs) are handled. However, I picked up some pace during the last couple of weeks and I'm determined to finish this implementation during the following weeks (some quirks with the tests have been haunting me, but I think I figured most of them out by now). After that, I will implement a second alternative implementation (to compare to, mostly for the sake of my thesis), which will take some more time. I also added a couple of fancy test cases (the so called "dot-tests"), so that we can test complex object graphs a little bit easier (and also because it was kind of cool to have another language inside PyPy/RPython, even if it was only for the tests...), with more test cases to come (the current ones are a bit messy). None of the new changes concerning low-latency applications are currently integrated, but that should not be too hard. I guess it won't make much sense for me to join you at this year's winter sprint, especially as I won't be able to get there before Thursday, but I might be able to join you over the IRC channel (or some other form of communication if you like). If there is anything that is worth discussing please let me know! Also feel free to comment on my code, but beware that I might change some things once I try to do some optimizations (probably not many, but at least fix the worst issues) and make it a little bit more readable. You can find my code on the cpyext-gc-cycle branch.<https://bitbucket.org/pypy/pypy/commits/branch/cpyext-gc-cycle> Looking forward to hearing from you! Greetings, Stefan

2 2

Help with a revamped ww.pypy.org web site
by Matti Picus Jan. 8, 2020

Jan. 8, 2020

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.

2 2

Version 7.3.0rc3 tarballs are availabe for testing
by Matti Picus Dec. 21, 2019

Dec. 21, 2019

1 0

pypy specific code flags DONT_IMPLY_DEDENT and SOURCE_IS_UTF8
by Rocky Bernstein Dec. 16, 2019

Dec. 16, 2019

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.

2 4

Version 7.3.0rc1 tarballs are availabe for testing
by Matti Picus Dec. 11, 2019

Dec. 11, 2019

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

1 0