cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<ljwobker>
cfbolz: can I just post somewhere a snippet of code that reproduces the issue? The current code is proprietary but I can pretty easily sterilize it. Pastebin? Github issue? Mailer list? Whatever is easier for you guys...
LarstiQ has quit [*.net *.split]
sknebel has quit [*.net *.split]
blueyed has quit [*.net *.split]
sknebel has joined #pypy
LarstiQ has joined #pypy
blueyed has joined #pypy
ljwobker has quit [Remote host closed the connection]
<cfbolz>
woops, of course I find unpushed commits in my extradoc :-(
<kenaan>
cfbolz extradoc 0415a5f5f1ec /blog/draft/: new plots
<kenaan>
cfbolz extradoc b927dc27a328 /blog/draft/: add source of diagram
<antocuni>
mattip: squeaky's README seems to imply that the sock virtualenvs DOES work with newer pypys
<cfbolz>
antocuni: I would weaken the statement "Cython eventually will generate HPy code". we don't know whether that will happen for sure
<Dejan>
i use -m venv all the time
<antocuni>
well, stefan agreed on this when we discussed it at EuroPython
<cfbolz>
sure, but it's not a formal promise, and it feels strange to speak for another project
<cfbolz>
so maybe simply "could"
<cfbolz>
instead of will
<antocuni>
ok, true enough
<cfbolz>
should I do it?
<antocuni>
"Cython plans to..." ?
<mattip>
I am using virtualenv 15.1.0 and it does not work for me with the latest builds of pypy2 and pypy3 on x86 (portable builds)
<cfbolz>
antocuni: that's still a definite statement. if you want to write that we need to talk to stefan before posting, imo
<cfbolz>
"is considering" I could get on board with
<antocuni>
ok, +1 for "is considering"
<antocuni>
mattip: then maybe it's a new issue? I always used the stock virtualenv with portable builds with no problems
<cfbolz>
cool
<cfbolz>
antocuni: matti means his portable builds
<cfbolz>
not squeaky's
<antocuni>
cfbolz: please add it while you are doing the other edits, thanks :)
<antocuni>
I think mattip said that squeaky's builds work only with their own virtualenv
<mattip>
it seems portable pypy works, my portable builds do not
<mattip>
now what is the trick?
<antocuni>
I confirm that squeaky's build works with virtualenv==16.4.3
<antocuni>
mattip: what is the exact problem you are encountering?
<cfbolz>
antocuni: maybe also mention that Tim Felgentreff (phlebas) of GraalPython gave some input, to make sure that the design could also work there?
<antocuni>
+1
<mattip>
the part that makes both builds "portable" is that there are *.so shared objects in a directory called lib
<mattip>
somehow virtualenv knows to copy them with portable pypy, but not with my builds
<phlebas>
antocuni: we're already working on running the ultrajson example, too, but it'll take one or two more days, so don't mention that :)
<antocuni>
cfbolz: Windel Bouwman or rustpython is also following the project and commenting on some issues, although he didn't give any input specific to rustpython yet
<antocuni>
phlebas: wow!
<cfbolz>
ah, awesome
<antocuni>
mattip: do you need help with debugging or you are already on track?
<kenaan>
cfbolz extradoc c14cba0877bb /blog/draft/2019-12-hpy-sprint.rst: weaken claim about cython, mention Tim and Windel
<mattip>
I think I have a handle. I made pypy2_virt/lib read-only and got an exception when trying to recreate with virtualenv
<mattip>
with squeaky's portable builds
<cfbolz>
antocuni: done, great post imo
<antocuni>
thank you
<antocuni>
now I just need to remember the magic recipe to turn the rst into a blogger-friendly html :)
<cfbolz>
rst2html, then lost of manual editing
<antocuni>
nice typo :)
<mattip>
or copy-paste into blogger, and lost of manual editing
<cfbolz>
:-)
edd[m] has quit [Ping timeout: 264 seconds]
bendlas has quit [Ping timeout: 252 seconds]
agates[m] has quit [Ping timeout: 248 seconds]
extraymond[m] has quit [Ping timeout: 250 seconds]
<antocuni>
I suppose we could just put the patch in default
<antocuni>
maybe with an if to check that "lib" actually exists, in case anyone wants to make a non-portable build
<mattip>
+1
<mattip>
also windows, aarch64, s390x
<mattip>
don't have lib
<antocuni>
yes
<antocuni>
I see there are patches to sysconfig_pypy.py as well
<mattip>
that one is more controversial. It is so if you rebuild the cffi modules you get the portable ones.
<antocuni>
maybe there should be an official way to know from within pypy if this is a portable build or not? This way we can easily integrate all these patches with "if IS_PORTABLE_BUILD"
<antocuni>
ah
<mattip>
I think if you rebuild, you should have to specify which you wan
<mattip>
t
<antocuni>
I don't know enough details to have an informed opinion about this
<mattip>
the ssl and _curses patches have been redone into pypy already
<mattip>
except for the certificate thing: squeaky adds a sertificate.pem to the shipped pypy, I didn't. I modified the error message to say it is missing, and documented the certifi pypi package and how to use it
<antocuni>
how can you install certifi is sshl doesn't work?
<mattip>
pip ships a certificate for pypi use
<antocuni>
ah, cool
<mattip>
I consulted here with tumblweed a few days ago (misspelled to not ping him)
adamholmberg has joined #pypy
ekaologik has joined #pypy
<antocuni>
cfbolz: I need some help with pypy config/options
<antocuni>
I am trying to write a "_dummy_importlib" module for 3.6 to be used by tests instead of "_frozen_importlib" which is horribly slow
<antocuni>
and I'm trying to introduce the correct options to select one or the other
<antocuni>
ideally, _dummy_importlib should be the default for tests (but tests should be able to override it), and _frozen_importlib the default for translation
<antocuni>
and the two modules should not be present at the same time