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
epony has quit [Remote host closed the connection]
<isuruf>
An update from conda-forge. We have installers for PyPy (x86_64, ppc64le, aarch64) now which are self contained (except for glibc of course). It also comes with the conda package manager
<mjacob>
cfbolz: sorry for that! (although it seems like armin's changes created some conflicts.) still, next time i'll try to remember to do the merge myself afterwards.
<cfbolz>
matti managed :-)
* cfbolz
is bad at merging
<mjacob>
a colleague writes her bachelor's thesis about merge tools. i'm still waiting for some innovations to happen in this area. ;)
<isuruf>
Looks like wheel is depending on this broken behaviour to get the ABI tag
<isuruf>
changing it would break ABI tagging in wheel
<mattip>
isuruf: what does it do on python2?
<mattip>
anyhow, it should be fixed in latest nightly
<isuruf>
In python2, if that config var is not set, they fallback to a different method
<mattip>
there should be officially sanctioned protocols for this stuff :(
<mattip>
PEP425 never specified _how_ to get the tags, just what they _are_
<isuruf>
PEP 3149 said that the shared library tag shoud be EXTSUFFIX and SOABI is just the tag
* mattip
looking
<mattip>
so CPython is not compliant with that PEP?
<isuruf>
PyPy is not compliant
<isuruf>
CPython is
<isuruf>
PyPy nightly is compliant
<mattip>
according to that pep, sysconfig.get_config_var('SOABI') is 'cpython-32mu', which is only the ABI tag. CPython has both the ABI tag and the platform tag
<mattip>
pep 425 came 2 years later
<isuruf>
Ah, yes. That's messed up
<mattip>
whatever. Thanks for pointing it out and I will try to push a release soon
<isuruf>
> from wheel.pep425tags import get_abi_tag
<isuruf>
get_abi_tag() should give you the correct value
<isuruf>
pypy36_pp73
adamholmberg has quit [Remote host closed the connection]
<mattip>
module wheel has no attribute pep425tags
adamholmberg has joined #pypy
<mattip>
wheel 0.34.2
adamholmberg has quit [Read error: Connection reset by peer]
adamholmberg has joined #pypy
<isuruf>
```
<isuruf>
```
<isuruf>
Python 3.6.9 (1608da62bfc71e8ac775121dd0b21bb72e61c6ea, Mar 11 2020, 21:45:38)[PyPy 7.3.0 with GCC 7.3.0] on linuxType "help", "copyright", "credits" or "license" for more information.>>>> from wheel.pep425tags import get_abi_tag>>>> get_abi_tag()'pypy36_pp73'>>>> import wheel>>>> wheel.__version__'0.34.2'
<mattip>
sorry, my bad
<mattip>
right, so latest nightly break this
<mattip>
there is code specifically for dealing with removing the package tag, but only on CPython
<mattip>
isuruf: this seems bad. What caused you to start looking at this in the first place?
<isuruf>
I have a package that uses CMake to build the extension package which uses SOABI to tag the shared library
<isuruf>
And it was getting `name.pypy36-pp73.so` which PyPy doesn't understand
<mattip>
so that package should be using the "packaging" package instead
<isuruf>
Right. Or just `EXTSUFFIX`
<mattip>
I will back out ee95733490a9, it seems too risky right now
<isuruf>
Yes, that seems like the best option right now. Thanks
agates[m] has quit [Ping timeout: 245 seconds]
agates[m] has joined #pypy
<mattip>
cfbolz: I am fixing translation
<mattip>
on py3.6
<mattip>
strange, pypy/module/_cffi_backend/cbuffer.py seems broken on default
<mattip>
ahh, no, there is no MiniBuffer.descr_getitem on default
_whitelogger has joined #pypy
jacob22 has joined #pypy
rjarry_ is now known as rjarry
bbot2 has quit [Quit: buildmaster reconfigured: bot disconnecting]
<mattip>
gahh, detecting msvc versions is such a mess.
<cfbolz>
:-(
<mattip>
they assume you install the entire visual studio IDE, not just the compilers since only the IDE sets registry key/values that setuptools searches for
<mattip>
there is a fall back to "legacy", but it searches for the compilers via an install path scheme that is no longer followed
<mattip>
so I ended up replicating this legacy scheme by hand, copying things around
jacob22 has quit [Ping timeout: 256 seconds]
jacob22 has joined #pypy
jcea has joined #pypy
<mattip>
in the end we will end up backporting stdlib changes and unsupported packages to python2, which will become more and more painful
<mattip>
especially around setuptools, pip, wheels, distutils
YannickJadoul has joined #pypy
<cfbolz>
mattip: yes, it's unclear how long it will remain viable
<Alphare>
Hello there, Mercurial dev here. Would anyone with an old working directory of pypy send me a tarball of their working directory, .hg included? I am working on `hg status`'s performance, and I am setting up benchamarks for dirty working directories
<Alphare>
I would do something artificial, but I would rather have something more realistic of long-term use for each project
<cfbolz>
Alphare: with unchecked in files? or with uncommitted changes?
<Alphare>
(I'm specifically doing this for ignored files)
<cfbolz>
ah
<Alphare>
hg status -i | wc -l can tell you how many ignored files you have
<Alphare>
(you should probably gzip it before sending it heh)
<cfbolz>
Alphare: I can happily give you one, but I also have a ton of uncommitted (not ignored) files around
<Alphare>
it's no problem
<cfbolz>
(but also ~2000 ignored ones)
<Alphare>
cfbolz: that's perfect
<Alphare>
that's actually surprisingly little
<Alphare>
but I'm used to rust and npm dependencies in projects that create a *ton* of these
otisolsen70 has joined #pypy
<cfbolz>
Alphare: ok, uploading, will take a bit (it's about 1gb)
<Alphare>
thanks a lot
<cfbolz>
mattip: ah, that was too early. a lot of the new tests are skipped if the correct constants aren't exposed
<cfbolz>
so more work to do
<mattip>
do you get a nice report of skipped tests?
<cfbolz>
yep, going through them
<cfbolz>
AF_VSOCK seems possibly out of my league
<cfbolz>
ouch, seems there is quite a bit of stuff that we never implemented because tests are nicely skipped
<cfbolz>
recvmsg_into is a 3.3 feature
<isuruf>
Is it possible to make it error at build time if a python extension is using a Python/C API function not implemented in PyPy instead of the current symbol error?
<mattip>
isuruf: if you build on windows it will yell about missing symbols by default. You can use -Wimplicit-function-declaration in gcc
<isuruf>
Thanks
<isuruf>
mattip, btw, is it okay to open issues about these missing symbols, or are they known?
<mattip>
isuruf: we could add -Wimplicit-function-declaration to the sysconfig flags
<mattip>
yes please. Some of the known ones may be "won't fix" since they are leaky internal APIs