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
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*
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
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
