cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
dustinm has quit [Ping timeout: 245 seconds]
dustinm has joined #pypy
jcea has quit [Ping timeout: 264 seconds]
ruth2345345 has quit [Ping timeout: 260 seconds]
andrewsm1dina has quit [Read error: Connection reset by peer]
andrewsmedina has joined #pypy
ruth2345345 has joined #pypy
jcea has joined #pypy
jcea has quit [Ping timeout: 260 seconds]
<arigato> mattip: hi! can you have a quick look at ? maybe our pypy3 binaries for windows contain a broken "python.exe" in them (but python3.exe and pypy.exe and pypy3.exe work)
<arigato> tell me if you need someone to actually test it on windows
<mattip> it works for me. I commented on the question.
<arigato> thanks
dylanyoung has joined #pypy
<dylanyoung> Is this irc still used?
<Hodgestar> Yes. :)
<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 :)
<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 and tool/pytest/appsupport
<dylanyoung> Correct?
<dylanyoung> Also, I was curious. Is it possible to test threading on an untranslated pypy?
<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)?
<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.
<mattip> that is not a simple task. How would you even start up multiple subinterpreters in PyPy?
<mattip> Whenever I see "just be a matter of" in reference to PyPy, I read "danger, deep rabbit hole ahead"
<mattip> Our test running infrastructure is based on a very old vendored pytest and is quite complicated
<mattip> > Is it possible to test threading on an untranslated pypy
<mattip> yes, but there are caveats
<dylanyoung> 1) that's what I've implemented. That part is already working (untranslated and unthreaded) with the PEP734 API.
<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.
<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.
<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.
<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.
dylanyoung has quit [Ping timeout: 252 seconds]
dylanyoung has joined #pypy
dylanyoung has quit [Ping timeout: 260 seconds]
dylanyoung has joined #pypy
jcea has joined #pypy