Mailman 3 June 2020 - 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

Changing the PyPy download page
by Ram Rachum 24 Sep '20

24 Sep '20

Hi everyone! The last week, I've been talking with Matti about ways in which PyPy could be friendlier to new users, and what to do about that. One of the examples I raised in which PyPy is, in my opinion, giving newbies a hard time, is the download page. In my opinion it's way too complicated and not geared for people who want to use PyPy but are less knowledgeable, or less interested in putting in time to understand the subtleties of JIT vs no-JIT vs STM, etc. We discussed that maybe I should make that change and open a PR for it. I said I'm willing to do that, (and learn some Mercurial and Nikita on the way) if I know there's general support in this list to that direction of change; I expect a code review, but I want to know before I start that this change is wanted. Here are a few of the changes I'd like to make: 1. Push the list of binaries to the top. 2. Put Python 3 above Python 2. 3. Move the instructions for building to a separate page. The intersection of the set "people who are interested in build instructions" with the set "people who have a hard time pressing an additional link to get to the build instruction" is very small indeed. 4. I might also put icons of Windows, Mac and Linux near their respective binaries. 5. Ideally I would have auto-detection that gives you the binary to your OS, but I'm not sure I want to work that hard. You get the general idea: Treating PyPy more like a finished product and less like a C library. What do you think? Thanks, Ram.

6 8

We have officially moved to foss.heptapod.net/pypy
by Matti Picus 01 Sep '20

01 Sep '20

As reported in the recent blog post https://morepypy.blogspot.com/2020/02/pypy-and-cffi-have-moved-to-heptapod.…, please do not add content to bitbucket.org/pypy or any of the repos there. From now on use https://foss.heptapod.net/pypy/pypy. The repos will continue to live on bitbucket until May 31, and we are still hosting our wiki and downloads there, but activity should move to the new instance. Anyone can open an issue, but in order to commit (as explained in the previous mail) you will need permissions on the repo. The FOSS heptapod instance does not support personal forks, so for now PRs will be branches (heptapod recommends topic branches but some of us are not convinced) on the main repo. Also take a look at the facelift on www.pypy.org. Matti

3 2

the end of bitbucket, heptapod, and permissions
by Matti Picus 29 Jun '20

29 Jun '20

2 1

Fwd: pypy | Proposed changes to make pypy3 work when embedded within a virtualenv (!728)
by Armin Rigo 15 Jun '20

15 Jun '20

Hi, I'm very reluctant to make changes relating to virtualenv and installation in general, because I have very limited experience with that topic (particularly on Python 3). Ronan or someone else, could you please double check it? Thanks! Armin ---------- Forwarded message --------- From: Armin Rigo <foss(a)heptapod.net> Date: Sun, 14 Jun 2020, 10:20 PM Subject: pypy | Proposed changes to make pypy3 work when embedded within a virtualenv (!728) To: <armin.rigo+heptapod(a)gmail.com> Armin Rigo <https://foss.heptapod.net/arigo> created a merge request: Branches: topic/py3.6/embedded-in-virtualenv to branch/py3.6 Author: Armin Rigo Assignees: This fixes cffi#460 <https://foss.heptapod.net/pypy/cffi/issues/460>. Unsure it is the correct fix, though, so I'll seek review by making a merge request. — Reply to this email directly or view it on GitLab <https://foss.heptapod.net/pypy/pypy/merge_requests/728>. You're receiving this email because of your activity on foss.heptapod.net. If you'd like to receive fewer emails, you can unsubscribe <https://foss.heptapod.net/sent_notifications/c51e0ea364d4bbe059ddb8297af71d…> from this thread or adjust your notification settings.

1 0

Dough about prevision on updating pypy to python 3.8
by João Victor Guazzelli 14 Jun '20

14 Jun '20

Hello there I'm a brazilian developer in hope to use pypy, or should I say, in need to use pypy. I'm thinking about upgrading my code to python 3.8 but pypy is mandatory. That being said my dough is if pypy is compatible with 3.8 and if it is not if there is a prevision on that. Thank you so much for your attention.

2 1

Trouble with first commit
by shao lo 10 Jun '20

10 Jun '20

i'm having trouble following the steps for my first simple commit (looking at contributing.html). I applied for and was granted access yesterday. I've connected my github account. When i try to do the push i get 'remote: user "heptapod-write" is not authorised to publish changesets' Any help would be much appreciated! ...the steps I followed mkdir local_src cd local_src hg clone https://foss.heptapod.net/pypy/pypy cd pypy # edit pypy/.hg/hgrc # add # username = shaolo1 <shao.lo(a)gmail.com> hg pull && hg up hg branch build_link_fix # ...edit file build.rst hg commit -m "Replaced bad link to getting-started-dev.html with contributing.html." hg push pushing to https://foss.heptapod.net/pypy/pypy searching for changes abort: push creates new remote branches: build_link_fix! (use 'hg push --new-branch' to create new remote branches) hg push --new-branch pushing to https://foss.heptapod.net/pypy/pypy searching for changes http authorization required for https://foss.heptapod.net/pypy/pypy realm: GitLab user: shaolo1 password: remote: adding changesets remote: adding manifests remote: adding file changes remote: user "heptapod-write" is not authorised to publish changesets: a2ceee6a2d79 abort: push failed on remote

2 1

help needed: libffi and recent macOS
by Matti Picus 02 Jun '20

02 Jun '20

3 9