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
Lightsword has quit [Ping timeout: 252 seconds]
Lightsword has joined #pypy
ltfish has quit [Ping timeout: 246 seconds]
ltfish has joined #pypy
jcea has quit [Ping timeout: 248 seconds]
eponym has joined #pypy
epony has quit [Remote host closed the connection]
eponym has quit [Remote host closed the connection]
jinsun has quit [Read error: Connection reset by peer]
alice has quit [Remote host closed the connection]
alice has joined #pypy
<cfbolz> yay, test_patma finally passes on py3.10 :-)
<cfbolz> (that's the pattern matching test suite, which is very thorough and it took quite a while to get all the corner cases)
<LarstiQ> cfbolz: cool!
<mattip> yay
<cfbolz> didn't read it yet, but this paper sounds quite interesting, does pypy jit parameter tuning as an example use case:
epony has joined #pypy
<ronny> I'm wondering, have there been any attempts to work towards having rpython work on python 3
<ronny> My rudimentary understanding from back then is that core failure points are changed apis, bytes vs Unicode and new byte codes
<mattip> yes, there is a branch rpython3
<mattip> as I wrote in the mail to pypy-dev, the only use of unicode is for windows
<mattip> there is a bit of changed apis, not too bad
<mattip> the byte code changes will be the hardest: we will need to target a particular version since the bytecodes change each version
<ronny> mattip: i presume there is no way to iteratively integrate this into the mainline? (i remembre the pain involved in having such long running branches
<mattip> makes sense to merge the api changes asap
<mattip> the rpython branch changes much more slowly than the pypy branch, so there is less bitrot
<mattip> and there are always more pressing things to do, so merging the changes has not yet happened
<ronny> unfortunate - i do have a long term wish of eventually getting pypy onto modern pytest, but im also rather stretched, however i would like to make the occasional excourse
greedom has joined #pypy
epony has quit [K-Lined]
greedom has quit [Read error: Connection reset by peer]
greedom has joined #pypy
<arigato> cfbolz: yes, that threads starts by being about hash(None) I believe
<arigato> mattip: CondaEcosystemModifyDllSearchPath_Init() cannot be written at app-level if its goal is to locate libpypy3-c.dll... it should just be rewritten in C and put into the stub executable
<mattip> then the exe will have to do LoadLibrary("libpypy3-c.dll") rather than linking with it
<mattip> is there a reason to prefer linking over LoadLibrary?
<mattip> the problem is not so much locating libpypy3-c.dll rather locating the run-time dependencies of libpypy3-c.dll
<arigato> cfbolz: thanks for the paper!
<mattip> but on the other hand, using LoadLibrary will allow flexibility like RPATH
<arigato> we're talking about windows, right? aren't all dependencies DLLs that we provide and put in the same place as libpypy3-c.dll?
<arigato> if conda so far puts libpypy3-c.dll and the other DLLs in different directories, that just looks like asking for trouble for nothing, to me
<mattip> the theory is that, like RPATH, then you can update those other DLLs without touching the libpypy3-c.dll
<arigato> and you can't do that if they are all in the same folder, for reasons?
<mattip> for instance, there is a conda package called libbz2. It provides the libbz2.dll.
<mattip> PyPy depends on it, as does maybe R and some other c++ package
<arigato> ah, right, so we do os.add_dll_directory() more than once--sorry, I missed that
<arigato> I thought the other DLLs had to be copied into pypy anyway, and the whole thing was just arranging for them to be in some subfolder to be nice
<arigato> conda has got the same problem with every package, not only pypy, right?
<cfbolz> Didn't study it yet in detail either though
<arigato> every package that needs DLLs that come from a different package
<mattip> yup. They patch CPython too
<arigato> OK, what I would try is to copy-paste that C code into our tiny executable
<mattip> don't we have to then use LoadLibrary('libpypy3-c.dll') instead of linking to it?
<mattip> I don't see how cpython gets around this
<arigato> maybe in CPython all the DLLs are loaded only when you import some module?
<arigato> but yes, using LoadLibrary('libpypy3-c.dll') instead of statically linking to it, that should be easy too
<arigato> at this point I would simply write a C program by hand, and compile it, and use that instead of pypy3.exe
<mattip> +1. So I am back to my question about if this is an OK thing to do. Is there any reason to fear using LoadLobrary over linking?
<arigato> I don't think so
<arigato> at least, not that I can see
<mattip> cool, thanks
<arigato> :-)
<mattip> (indeed, cpython does not need libbz2.dll, libexpat.dll, ffi-8.dll for python3.9.dll, only for c-extension libraries like _imp)
greedom has quit [Ping timeout: 248 seconds]
<mattip> I think I finished the _ssl changes for 3.10
<mattip> I thought it would magically fix lib-python/3/test/, but it seems that test still hangs
<mattip> ahh, it is some thread cleanup problem: on cpython the thread stops, on pypy I needed to emit a command
jinsun has joined #pypy
jcea has joined #pypy
derpydoo has joined #pypy
derpydoo has quit [Ping timeout: 260 seconds]