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
Dear developers of PyPy:
I found that there might be a little bug in `unicodeobject.py`.
Our project relies on `sys.setdefautencoding('utf-8')` to handle string
encoding things(we use Python2.7), which is not a good practice though,
when we
upgrade pypy to 7.1.0 and any version newer than it, our project stops
working with tons of UnicodeEncodeError exceptions. There is already an
issue 3329 <https://foss.heptapod.net/pypy/pypy/-/issues/3329#note_156942>
described
this problem, I left my comment
<https://foss.heptapod.net/pypy/pypy/-/issues/3329#note_156942> below it
which provided our solution to this problem. But I am not sure our solution
is the correct way,
and I tried to make a merge request but it then said that I don't have
write permission, so I decided to write an email.
I'm looking forward to hearing from you guys soon.
Best regards,
Kevin
And it's opensource, though many of the inputs are licensed.
The code is at https://stromberg.dnsalias.org/~strombrg/music-pipeline/ (
https://stromberg.dnsalias.org/svn/music-pipeline/trunk/)
It appears to be more than 10x slower.
I haven't profiled it yet. I believe it's probably the "Blocklisting
files..." part that's slow. That part is O(n*m), and seems to take
forever. It's heavy on regular expressions.
Are regular expressions expected to be slow on Pypy3?
Thanks.
--
Dan Stromberg
I would like to release new versions of PyPy for python2.7 and
python3.7. I think 3.7 has matured to the point that we can drop both
the "beta" label and the python3.6 release. The python3.8 version is not
yet ready for an "alpha" label.
There are three issues (one about running "pypy -Wonce ..." and warnings
inside a decorator, and two having to do with sqlite3) marked as
blockers [0]. Are there more blockers? Anyone want to take a look at
fixing them?
Matti
[0] https://foss.heptapod.net/pypy/pypy/-/milestones/3
