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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]