19:09 <arigato> mattip: hi! can you have a quick look at https://stackoverflow.com/questions/77812215/what-is-the-purpose-of-python-exe-in-the-pypy-binary-distribution ? maybe our pypy3 binaries for windows contain a broken "python.exe" in them (but python3.exe and pypy.exe and pypy3.exe work)

19:09 <arigato> tell me if you need someone to actually test it on windows

19:37 <mattip> it works for me. I commented on the question.

19:46 <arigato> thanks

20:00 <dylanyoung> Is this irc still used?

20:24 <Hodgestar> Yes. :)

20:34 <dylanyoung> Fantastic! I've been familiarizing myself with the pypy code by trying to implement PEP734 (multiple interpreters in stdlib). Not translating yet, but so far all good. Glad to know there are still folks here :)

20:38 <dylanyoung> I'd like to modify the test runner to be able to run applevel tests in a (arbitrarily nested) subinterpreter. That should just be a matter of modifying conftest.py and tool/pytest/appsupport

20:38 <dylanyoung> Correct?

20:38 <dylanyoung> Also, I was curious. Is it possible to test threading on an untranslated pypy?

20:47 <dylanyoung> Another question I had was whether it's possible to force the gc to track objects in a subinterpreter differently (e.g. give them their own nursery and arenas in incminimark)?

20:50 <dylanyoung> After this I'd like to dive more into rpython itself. I'm curious if anyone here has thoughts on implementing a zig backend for pypy.

21:42 <mattip> that is not a simple task. How would you even start up multiple subinterpreters in PyPy?

21:44 <mattip> Whenever I see "just be a matter of" in reference to PyPy, I read "danger, deep rabbit hole ahead"

21:44 <mattip> Our test running infrastructure is based on a very old vendored pytest and is quite complicated

21:45 <mattip> > Is it possible to test threading on an untranslated pypy

21:45 <mattip> yes, but there are caveats

21:50 <dylanyoung> 1) that's what I've implemented. That part is already working (untranslated and unthreaded) with the PEP734 API.

21:52 <dylanyoung> Basically, I just want a way to run all existing tests through that API instead of at top level. I did take a quick tour through the pytest code and it's a bit convoluted, but not too bad. I think I should just need to modify the arg parsing and then the ApplicationTestCase class to use those args appropriately. I could be missing something though.

21:55 <dylanyoung> So instead of the tests simply running exec directly on the test code, they'd create a subinterpreter i and run i.exec_sync on the test code.

21:56 <dylanyoung> The tricky part will be probably the tracebacks, but I've already got those passing up via a TracebackException as per pep734, and it can't be worse than my current tests that just call exec_sync internally, lol.

22:16 <dylanyoung> Anywho, I'll give it a shot and let you know how it turns out. Aside from that my next steps are modifying the GIL to be per interpreter, threading support, and migrating my commits to git.