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

Migration from Bitbucket to ???
by PIERRE AUGIER Oct. 1, 2019

Oct. 1, 2019

Hi, I posted this message in https://bitbucket.org/pypy/pypy/issues/3082 but apparently, it's better to post it in this list, so here it is: As explained here https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket, Mercurial features and repositories will be officially removed from Bitbucket and its API on June 1, 2020. I guess you thought about what to do for PyPy repository and PyPy development. I am also a Mercurial user and I am facing the same problem for some repositories. Thus, I am very interested to know what you plan to do. In particular, I am looking for a good forge for the Transonic project (https://transonic.readthedocs.io), which by the way is compatible with PyPy3.6 (currently only the nightly builds) and could help a wider adoption of PyPy3 for projects using the Python scientific stack (just by accelerating the numerical kernels using Numpy and let PyPy accelerate pure Python code). I follow the Heptapod project https://heptapod.net/ (a friendly fork of GitLab to bring very good Mercurial support). It seems to me that it starts to be nearly production ready and that it would nicely fit your workflow with Mercurial. Of course, it would be very convenient if a common instance (free to use for simple users until a certain point) could be setup (something somehow similar to Github, but with Mercurial support). Even for PyPy, it would be good in terms of visibility. I also heard that your repository would have to be fixed to be able to use Heptapod. What is the current status of these issues for PyPy? Have you already decided what to do? Best regards, Pierre -- Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16

3 2

Testing recent changes to JSON decoding
by Matti Picus Sept. 23, 2019

Sept. 23, 2019

Carl recently merged a deep change to the JSON decoding code (thanks!!). I would like to add it to the upcoming release. If you have an interesting JSON file, maybe even some broken ones that exist in the wild, could you give a latest nightly default (python2) or py3.6 a spin? In addition to knowing that the code works, it would be nice to hear how much speedup it gives. Thanks, Matti

1 0

Linux x86-64 binary (64bit, built on Ubuntu 14.04) - much slower implementation warning
by Sapna D'Souza Sept. 19, 2019

Sept. 19, 2019

Hi, I am benchmarking python vs pypy and tried running my code using Linux x86-64 binary (64bit, built on Ubuntu 14.04) <https://bitbucket.org/pypy/pypy/downloads/pypy3.6-v7.1.1-linux64.tar.bz2> from the downloads section of pypy.org I observe the following when I execute my scripts: much slower implementation (libssl.so.1.0.0: cannot open shared object file: No such file or directory) Can someone let me know if there is a way to get past this or if this will be fixed in an upcoming release? I am seeing the run time more than double when compared to regular python with this version. Thanks, Luna

2 1

Package Installation
by Arthur Coimbra Sept. 13, 2019

Sept. 13, 2019

Hello pypy team, I'm not sure if I'm installing packages for pypy correctly as I can't solve the following issue: [image: image.png] Any help would be much appreciated. Best regards, Arthur

2 2

Time to start a release cycle?
by Matti Picus Sept. 8, 2019

Sept. 8, 2019

1 0