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