Mailman 3 - pypy-dev

Contribute a RISC-V 64 JIT backend
by Logan Chien 12 Aug '24

12 Aug '24

Hi all, I would like to contribute a RISC-V 64 JIT backend for RPython. I have made some progress at the end of 2023. ## Status My prototype can pass the test cases below: * test_runner.py * test_basic.py and almost all test_ajit.py related tests (except test_rvmprof.py) * test_zrpy_gc_boehm.py I am still working on test_zrpy_gc.py though (p.s. I can pass this if I disable malloc inlining). I haven't done a full translation yet. ## Logistic I wonder how you would like to review the patches? I have roughly 73 pending commits. Each commit has a specific reason for change and corresponding test cases (if applicable). Is it better to just send one GitHub Pull Request containing all of them? Or, do you prefer one commit per Pull Request? Thank you. Regards, Logan

5 28

Windows zip file for pypy3.10-v7.3.16 is not completed
by yanglei 24 Apr '24

24 Apr '24

Hi PyPy developer team, Glad that you have released the new version for pypy3.10-v7.3.16 recently, but there is a little problem for this windows zip file. Maybe this file pypy3.10-v7.3.16-win64.zip ( https://downloads.python.org/pypy/pypy3.10-v7.3.16-win64.zip) is not completed, the sha256 value is different from you wrote on the website ( https://www.pypy.org/checksums.html). Official Website sha256: e08415a2f35c6ecf2342b504bdfde11e4c5eca3fc5ef7fd2214ff064a5a54396 pypy3.10-v7.3.16-win64.zip Actual sha256: 95ff7c3f23098307de9bea5ea75f47c6c4d615c07bee2e841aecef10e751286b pypy3.10-v7.3.16-win64.zip Hope you can check with this issue, thanks in advance. Have a nice day!

2 4

Release of pypy 7.3.16
by Matti Picus 23 Apr '24

23 Apr '24

I have released PyPy v7.3.16, which includes - bugfixes for the garbage collector - updates to the upstream stdlib for security issues Please try it out and report any problems. Matti

1 0

Fwd:
by Emre Yıldırım 26 Feb '24

26 Feb '24

---------- Forwarded message --------- From: Emre Yıldırım <emreyildirim412(a)gmail.com> Date: 26 Feb 2024 Mon at 14:27 Subject: To: <pypy-dev-owner(a)python.org> Hello, I am currently a 3rd year computer science student, studying at University of Manchester and my main project is to measure the difference between pypy and python. Currently, I ran some tests on pypy 3.9 and pypy 3.10. I am seeing that when I ran the experiment with multi-threading, I saw that pypy 3.10 is using more time with processing cpu and using more time in cpu operations. However, in pypy 3.9 when I run the experiments it is using less time on cpu in multi threading mode. I will also talk about that in my report and I want to ask if there is any specific reason for this because isn't pypy 3.10 should also be faster in processing cpu's. Kind regards, Emre

1 0

Release v7.3.15 of PyPy
by Matti Picus 15 Jan '24

15 Jan '24

I have prepared a new release of PyPy. This is mainly a bugfix release to fix backward compatibility in c-extensions that use the buffer protocol. It also includes chages from our move to Git/Github. The pre-release tarballs are now on https://buildbot.pypy.org/pypy/ (until the CDN percolates them out to https://downloads.python.org/pypy/), the checksums are on a Pr to pypy.org at https://deploy-preview-110--keen-mestorf-442210.netlify.app/checksums. The release notes are at https://doc.pypy.org/en/latest/release-v7.3.15.html. Please test out the source tarballs, they have changed since they are from a git repo. I plan to release officially later today. Matti

1 0

Moving to github
by Matti Picus 02 Jan '24

02 Jan '24

Now that 7.3.14 has been released, I would like to move the canonical repo for pypy and rpython to github. Reasons: - foss.heptapod.net is not well tracked in google/bing/duckduckgo search, so people find it hard to search for issues in the project - since the site has tightened its spam control, we get reports that users create issues only to have them flagged as spam - open source has become synonymous with github, and we are too small to change that - Much of the current development comes as a reaction to fixing issues. Tracking interlocking issues is easier if all the code is on the same platform - The FAQ [2] presents two arguments against the move. Github notes [3] solves much of point (1), although not entirely. But the main problem is point (2), it turns out that __not__ moving to github is an impediment to contribution and issue reporting. - As development effort winds down, github is a better archive for PyPy than foss.heptapod.net. I cannot predict the future, but if there is a move to revive the project, or to move to another platform, I believe github will provide a better jumping-off point as well. And since the repo at foss.heptapod.net will not be deleted, even if I am wrong I expect the effort to port the issues and commits from github will be manageable. - People who wish to continue to use mercurial can add a cron job github action to pull the changes from foss.heptapod.net across to github - github is more resource rich than foss.heptapod.net. We can add CI jobs to replace some of our aging buildbot infrastructure (still using buildbot 0.8 and python2). Technique: These steps will be done in a private repo - I will convert the repo to git and add a note to most of the commits (where I can) which will allow using "git log --notes=branch" to determine which branch a commit came from. More details at [0] - I will convert the issues and PRs to github via [1]. Using a private repo prevents spamming issue authors with emails about the transfer. Then I will make the repo public: - Move it to github.com/pypy/pypy - Freeze the issue tracker at https://foss.heptapod.net/pypy/pypy/-/issues, and add a message that development has moved - Write a blog post - Modify the links in the documentation - Activate the github action in [3] to add a branch note to each git commit Anything else? Any suggestions to make the transition easier? Matti [0] https://gist.github.com/mattip/b6752c164a075c2aa53f4069e9c30573 [1] https://github.com/piceaTech/node-gitlab-2-github [2] https://doc.pypy.org/en/default/faq.html#why-doesn-t-pypy-use-git-and-move-… [3] https://github.com/Julian/named-branch-action

7 9

Is the hash field optimization still present
by Joannah Nanjekye 28 Dec '23

28 Dec '23

Hello. I read about the hash field optimization here: https://www.pypy.org/posts/2009/10/gc-improvements-6174120095428192954.html But when I query object.__hash__(4) on the latest pypy branch, it returns, I expected a type error. I stand to be corrected obviously. -- Best, Joannah Nanjekye *"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis*

1 1

Release of v7.3.14
by Matti Picus 25 Dec '23

25 Dec '23

I have released v7.3.14 of pypy2.7, pypy3.9, and pypy3.10. Please check it out. The main new feature is support for HPy 0.9. There are also bugfixes and smaller enhancements. Matti

1 0

How do I compile pypy with debug symbols?
by buddy.lumpkin＠gmail.com 14 Dec '23

14 Dec '23

Hi All, I have a large code base that I am trying to optimize. I have a flame graph that tells me that it spends about 30% of it's time in pypy_g_ArenaCollection_rehash_arena_lists. Unfortunately, I can't see the rest of the call stack, so I am trying to compile a debug version of pypy. I followed the instructions here: https://doc.pypy.org/en/latest/build.html I'm at the step where it tells you to run: make lldebug or make lldebug0, and i'm realizing there is no such target. Please help! --Buddy

4 4

merge of hpy-0.9
by Matti Picus 03 Nov '23

03 Nov '23

I merged the hpy-0.9 branch to py3.9. There are a few untranslated failures, and more extra_tests post-translation failures. Most of the extra_test failures are in the debug/trace/hpy_devel/importing tests which cannot really be checked untranslated. Help is welcome to try to debug if the failures are due to using pytest4.0, to something in the test harnesses, or whether there is an actual problem with the hpy backend implementation. Additionally, the branch crashes when importing NumPy from the hpy branch https://github.com/hpyproject/numpy-hpy. This is being tracked in issue https://github.com/hpyproject/numpy-hpy/issues/15. It seems the custom trace function necessary to keep the W_Root object associated with a HPyField is not being called. Again: help here is welcome. I can meet up on zoom or google meet if anyone would like to dive in and wants to talk about the problems. Matti

1 0