08:10 <cfbolz> mattip: the tracing fix could maybe be backported to 3.7 too

08:10 <cfbolz> mattip: do we still do that? or was the previous one our last 3.7 release?

09:57 <fijal> there is a fuckton more issues

09:58 <fijal> e.g. wget refuses to connect to pypy.org (some probably old version of wget that worked fine just the other day)

10:22 <mgorny> fijal: maybe you have old ca-certificates?

10:29 <vstinner> hi. FYI I wrote https://www.python.org/dev/peps/pep-0670/ proposing a plan to convert macros to regular functions in the Python C API. it's a long term plan, i hope that i will help PyPy ;-)

10:29 <vstinner> (in the short/mid long, macros may first be converted to static inline functions, to fix at least their API)

10:33 <fijal> mgorny: something like that. The point is it was working, now it's not, due to zero action on my side

10:33 <fijal> cfbolz: do you have any clue about various kinds of strange buffers in rlib/buffer.py?

10:33 <fijal> do they do anything useful? It seems to me like they were written with no real performance in mind

10:35 <fijal> I'm pretty sure RawByteBuffer requires memory pressure for example

10:39 <fijal> arigato:

10:41 <ctismer> vstinner: that's great!

10:42 <vstinner> ctismer: it's a shy PEP. i still want to continue the work on PEP 620 which plans to make all structures opaque, and for example fix macros to disallow using them as l-value: Py_TYPE(obj) = new_type (now an error in Python 3.11)

10:43 <vstinner> but it's way harder to write the rationale section :-(

10:50 <the_drow> FYI cffi doesn't work on the nogil fork https://github.com/colesbury/nogil/issues/19

10:51 <vstinner> the_drow: booh, it should use Py_REFCNT() and Py_SET_REFCNT()

10:52 <vstinner> the_drow: nogil has something way more complex than just a "PyObject.ob_refcnt" number :-)

10:57 <mattip> cfbolz: I am not sure whether there will be another 3.7 release

10:57 <mattip> CPython3.7 is in security-fix only mode until 2023-06

10:57 <mattip> and is still in active support on conda

10:58 <mattip> so I guess we should keep backporting fixes to it and keep merging to py3.8 through it

10:58 <mattip> but not do anything to specifically fix bugs on 3.7 before 3.8

10:59 <the_drow> vstinner: Would you mind creating an issue about it?

11:00 <vstinner> the_drow: for the cffi+nogil issue? i'm not really interested to see this issue being fixed, le so i let you handle ;-)

11:00 <the_drow> Ok :)

11:02 <mattip> I would like to stop using pypy/doc/whatsnew*

11:02 <mattip> i.e. delete the *head* files and remove the test

11:03 <mattip> it is not helpful when creating the release notes, since anyway not everything is in it

11:03 <mattip> and is a maintenance burden

11:07 <the_drow> Celery has the same problem

11:08 <the_drow> But it is convenient for users to read 🤷

11:20 <mattip> the_drow: comparing https://doc.pypy.org/en/latest/release-v7.3.6.html#changelog to

11:20 <mattip> https://doc.pypy.org/en/latest/whatsnew-head.html (for default) and https://doc.pypy.org/en/latest/whatsnew-pypy3-7.3.6.html (for 3.7),

11:20 <mattip> which do you prefer?

11:21 <the_drow> The latter since it's shorter

11:22 <mattip> the release note is the hand-crafted changelog I do from the hg commits,

11:22 <mattip> the "whatsnew" is the one that is built up as PRs are merged

11:24 <the_drow> If you manage to force your contributors to add those notes, that's great. For celery, we the maintainers need to add that document with every minor release.

12:34 <cfbolz> mattip: I am fine with depreciating whatsnew if you feel like it's no longer useful

12:35 <cfbolz> We could switch to eg CPython's tool if we switch to github

15:29 <ctismer> probably much energy was put into all the mercurial support tools, right?

18:21 <cfbolz> mattip: so I went ahead and made a 3.9 branch

18:21 <cfbolz> mattip: will probably need some help with the stdlib at some point :-(

19:59 <mattip> cool. Does more work need to be done on the interpreter before adding the stdlib?