Mailman 3 February 2022 - pypy-dev

PyPy Winter Sprint + cpyext
by Stefan Beyer 21 Dec '22

21 Dec '22

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

BUILDING PYPY FROM SOURCE ASSERTION ERROR
by Elijah Okello 26 Feb '22

26 Feb '22

Hello Pypy Team, I am trying to build pypy from Source and I keep on getting an Assertion error whenever I try to build it with a different gc other than the default. The error I get is this [translation:ERROR] AssertionError Processing block: block@62[index_362...] is a <class 'rpython.flowspace.flowcontext.SpamBlock'> in (rpython.memory.support:262)AddressDeque.popleft containing the following operations: v3921 = getattr(self_10008, ('oldest_chunk')) v3922 = getattr(v3921, ('items')) result_37 = getitem(v3922, index_362) v3923 = add(index_362, (1)) v3924 = setattr(self_10008, ('index_in_oldest'), v3923) --end— How can I solve this issue? Please help me. Is there something I am not doing right?? Regards Okello Ivan Elijah Software Engineer

2 1

PyPy3.7-v7.3.8 broke binary compatibility
by matti picus 24 Feb '22

24 Feb '22

Once again, I broke ABI compatibility with the new release. I re-added a field to PyDateTime_CAPI that should have been part of the original PyPy3.7 release, but was missed, and so should be left out of PyPy3.7 v7.3.x. This causes segfaults when using PyPy3.7-v7.3.8 on wheels built for PyPy3.7-v7.3.7 and older. Please do not build packages with PyPy3.7-v7.3.8 for general release because they will not work on older PyPy3.7. What is doubly annoying is this is exactly why I needed to release v7.3.7 over v7.3.6. PRs welcome to suggest a test for this. A "hg diff" is a start, but it picks up refactoring and valid additions as well, so it needs to be a bit smarter. Maybe something with CFFI? Matti

2 1

PyPy 7.3.8 release
by Matti Picus 20 Feb '22

20 Feb '22

I have released PyPy v7.3.8. Thanks to all who contributed and tested and for moving PyPy forward. Matti

3 3

Differences between pypy2 and 3 and cffi
by Ioannis Foufoulas 17 Feb '22

17 Feb '22

Hi, I have an embedded function: @ffi.def_extern() def toint(input,insize,result): for i in range(insize): x = ffi.string(input[i]) result[i] = float(x) if x else 0 return 1 It seems that this runs around 30-40% percent slower in PyPy3 than in 2. Input is a char** c array and result is a float c array. The difference is not in ffi.string If having `result[i] = 1 if x else 0` it runs same in both versions. Any ideas?

5 4

PyCodeObject incompatibility
by Dmitry Kovner 15 Feb '22

15 Feb '22

Hello! I'm trying to build a low-level C API extension of cPython to be used in PyPy. The extension extensively uses some fields of PyCodeObject ( https://github.com/python/cpython/blob/f87e616af038ee8963185e11b96841c81e8e…): co_firstlineno, co_stacksize, co_consts and so on. However, it seems these fields are not defined in the similar structure of the PyPy implementation: https://foss.heptapod.net/pypy/pypy/-/blob/branch/py3.8/pypy/module/cpyext/…. Is it possible to get values of these fields using PyPy C API somehow?

4 6

PyPy v7.3.8 rc1 now available
by Matti Picus 11 Feb '22

11 Feb '22

This is a release of 4 versions of python: 2.7, 3.7, 3.8 (no longer beta) and 3.9 (beta quality). Release note: https://doc.pypy.org/en/latest/release-v7.3.8.html Downloads: https:// checksums: https://www.pypy.org/checksums.html As soon as the CDN network updates the https://downloads.python.org/pypy/versions.json file, you can use them in github actions CI. Please try these out and report any problems. Note that we are having issues with the ARM8-64bit buildbot, so we are not releasing binary packages for that platform. Hopefully we will have an alternative for the final release. Matti

2 3

Making PyPy relevant
by Dima Tisnek 04 Feb '22

04 Feb '22

Dear PyPy folk, I had been a quiet supporter of your project for some years, but lately completely dropped off. I would like to state my reasons in hope that PyPy will not be completely forgotten and thus point a path forward, perhaps hypothetical, but one that I would very much like to see: #1 PyPy must track Python language versions (and CPython stdlib versions) You've released 7.3.8 with 3.8 support and I already use [Python language version] 3.9 in production and 3.10 in CI. (3.9 in prod only because some dependencies are missing a formal update, it will be 3.10 in no time) The components that run [Python language version] 3.8 in prod are a mix of obsolete, unmaintained, and those whose developers are too busy with other things, there's no chance those components would switch to PyPy. You've released 3.9 beta support and I'm running [CPython] 3.11.0a4. I can't use your great work. Ideally PyPy would track these in lock-step (released at the same time); an acceptable compromise may be a 3-month delay. In short: for me (and probably mots developers) PyPy remains an academic exercise. Thank you, Dima Tisnek P.S. My wish list: #2 Move to GitHub already. Your current repo setup makes it impossible for the majority to of developers to contribute. #3 Focus on one major feature, that is visible to the developers, and not old -- it could be, for example, typing or async/await, but probably not multithreading. The impact of your amazing work is proportional to the number of users. The average user is interested more in language usability and frist-class language features; performance comes second.

5 4