Mailman 3 April 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

How can we make Python's C-API more friendly for cpyext?
by encukou＠gmail.com 24 May '22

24 May '22

Hello, I'm figuring out a strategy for the future of Python's C-API, and as one of the goals I'd like to make it friendly for non-C languages. I'd like to ask you for any suggestions, pain points or comments on how to better do that. Would you like to help? I understand PyPy solved a lot of these issues and won't get too much benefit, but I'd like to improve things for future projects. I'm also aware of HPy, a long-term solution. I'd like to meet in the middle. I started a [Google doc](https://docs.google.com/document/d/1fDfF7JanOEyQ9awhKE87-Ajp3H4k7qXL3c… to collect notes. If you don't mind Google, please feel free to comment there, but I'll be happy to discuss here as well. If you have a link to a document/rant, I'd love to go through it. In particular, I'd like to ask if any of the following would help, or would have helped in the past: - Regularity in strong/borrowed references (always returning strong references and taking borrowed ones) - Regularity in error handling (all functions should have a dedicated return value, an exception should be set set iff that value is returned) - Avoiding preprocessor macros - Avoiding bit fields - Avoiding enums - Exposing API/ABI information in a structured format, rather than C headers Is anything else missing from this list? Thank you for your time!

3 2

buildbot master upgrade to support python3 workers?
by Matt Billenstein 17 Apr '22

17 Apr '22

Hi, python2 is really long in the tooth - when are we planning to upgrade the buildbot master? I cannot install python2 from homebrew on macos any longer, the system python2 is really really old... thx m -- Matt Billenstein matt(a)vazor.com http://www.vazor.com/

3 5

How have you found compiling in OpenSSL and other libraries into your relocatable builds?
by Brett Cannon 01 Apr '22

01 Apr '22

I noticed that https://www.pypy.org/download.html says that "the linux binaries ship an OpenSSL library". Have you found that to be an issue in any way? Have users been accepting of it? I ask as I'm contemplating trying to get relocatable builds for CPython on Linux (to start), and I suspect the OpenSSL question is going to be one of the bigger/stickier discussion points and having some real-world experience/information on the topic would probably help.

3 2