05:00 <Corbin> It took a couple hours, but I figured out how to set up the pipes for a bidirectional subprocess: https://osdn.net/users/corbin/pf/cammy/scm/blobs/master/cammy-rpy/cammylib/jelly.py

05:47 <krono> neat

05:47 <krono> maybe this can go into rlib as a convenience method?

05:51 <Corbin> Possibly. This codebase is AGPL but I'm happy to make an exception so that this particular module can be copied. It's not a lot of code, but it took a lot of man pages.

06:10 <krono> jep

08:15 <ctismer> cfbolz: is mattip in holiday?

09:15 <ctismer> cfbolz: from the Python 3.9 docs:

09:15 <ctismer> The PyEval_InitThreads() and PyEval_ThreadsInitialized() functions are now deprecated and will be removed in Python 3.11. Calling PyEval_InitThreads() now does nothing. The GIL is initialized by Py_Initialize() since Python 3.7. (Contributed by Victor Stinner in bpo-39877.)

09:17 <ctismer> So this needs already to be fixed for the PyPython 3.9 version I guess?

09:22 <ctismer> cfbolz: as I understand it, `Py_Initialize` is currently explicitly not supported because it is (thought as) for embedding?

11:33 <cfbolz> ctismer: yes, I think so

11:38 <ctismer> cfbolz: So that situation is a little weird: Python 3.11 removes PyEval_InitThreads, which PyPy needs (also in Py3.9!) and replaces it by Py_Initialize, which PyPy does not support. 🤨

11:38 <cfbolz> yes, but I think the solution is to make pypy stop needing PyEval_InitThreads

11:39 <cfbolz> because the official solution is to make PyGILState_Ensure work

11:43 <ctismer> cfbolz: Ok, I just would like to know if I can put an #ifdef for version <= 7.3.8, or if that is not reliable. I now did a general #ifdef on PYPY_VERSION.

11:43 <cfbolz> ctismer: I don't think I can answer this question this exact minute ;-)

11:44 <ctismer> ok, nebbich ¯\_(ツ)_/¯

11:46 <cfbolz> ctismer: so I think you pick either of the two #ifdefs to make it work for now

11:46 <cfbolz> and then in the worst case you need to adapt :-(

11:47 <ctismer> 🖖

11:49 <ctismer> The general #ifdef this is more reliable because I can forget about the problem until I see an undefined symbol crash.

13:08 <Joannah> Is it only me, or the pypy repository on heptapod is not resolving i.e https://foss.heptapod.net/pypy/pypy

13:09 <cfbolz> yes, seems down maybe?

13:09 <nimaje> I get 502 Whoops, Heptapod is taking too much time to respond.

13:09 <Joannah> I think so

13:10 <cfbolz> marmoute: any idea?

13:10 <Joannah> Me too, 502

14:19 <cfbolz> seems buildbot.pypy.org is also 502

16:07 <marmoute> cfbolz: that's the upgrade. (as announced by the banner)

16:09 <cfbolz> marmoute: ah, thanks. The 502 page didn't have the banner ;-)

16:09 <Joannah> Seems back up now

16:10 <marmoute> cfbolz: yep. That's something Clever-Cloud/Georges will eventually smooth out, but surprisingly Gitlab has no integrated suppport for a "we are upgrading page"

16:10 <marmoute> And upgrade are quick but frequent

16:11 <cfbolz> marmoute: cool, thanks for all your work!

16:50 <ctismer> cfbolz: Another request from our devs: can `PyImport_ExecCodeModule()` please be changed from `char *` to `const char *`? We get complaints in Linux. Python has this since Python 3.6 at least.

17:00 <ctismer> (or fixed that in maintenance updates...)

18:54 <cfbolz> ctismer: that one is much simpler, I am on it

19:57 <cfbolz> ctismer: pushed that change

19:57 <cfbolz> (at least to the 3.8 branch, 3.9 coming at the next merge)

20:04 <ctismer> cfbolz: Thank you! (They said there is more, but I’ll wait until they complain concretely.

20:04 <cfbolz> ctismer: those are easy to fix, just give me a list