<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