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
oberstet has quit [Remote host closed the connection]
jacob22 has joined #pypy
jacob22_ has quit [Read error: Connection reset by peer]
forgottenone has quit [Quit: Konversation terminated!]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
<arigato>
thank you for backporting _pypy_openssl to pypy2
<arigato>
cfbolz: maybe attach the error message to the exception, instead of printing it? this way, it's harder to miss (and maybe there's someone who really tries to import and catches the ImportError and doesn't want things printed)
<cfbolz>
arigato: yes, but then you don't see the underlying error message
<arigato>
well no, python 3 is modern :-)
<arigato>
if you raise instead an except handler, you see both exceptions in the end
<arigato>
I think
<cfbolz>
arigato: ok, but it's also on pypy2 now ;-)
<arigato>
on pypy2 you can raise ImportError(str(e) + " explanation")
<cfbolz>
ok
<arigato>
unsure how you're meant to replace an exception on python 3, if you wanted to do that, btw
<arigato>
...ah, that's still the default, and you have new syntax to raise an additional error but keep the original one: "raise ImportError(..) from e"
<tos9>
exception chaining should totally get backported to pypy 2.8
* tos9
ducks
<cfbolz>
a lot of things should be, somehow
<cfbolz>
but that so much work
<tos9>
cfbolz: I mean, to be 67% more serious -- I think the part you're going to have to change probably isn't a ton more is it
<tos9>
Like, backporting the syntax probably sounds terrible to have to do -- but even if py2 remembered exceptions that were raised while handling other ones and gave code no way to modify that it'd be nice
mattip_ has joined #pypy
<tos9>
(I always wanted to write that for work as just a normal library since ISTM you can do most of what I care about without any changes to the interpreter, but now probably I don't care enough and those apps will just move to pypy3)
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
<arigato>
let's release pypy2 supporting python 2.8 on January 1st :-)
<arigato>
(I am 100% joking)
<mattip_>
since I removed _ssl, pypy/module/interpreter/test/test_appinterp.test_random_stuff_can_unfreeze is failing, it tries to import _ssl
<mattip_>
on py3.6 I made the test pass by not importing _ssl, but then the whole thing is nonsense.
<arigato>
I can try to figure that out
<mattip_>
it's ok, just the idea is to import an interp-level module that imports a mixed module with app-level code
<mattip_>
and now we don't have that situation anymore
<mattip_>
my question is: mock something, or delete the test?
<arigato>
"great" I suppose, though argh, it's another strange piece of the language---you either say "class Point2D(TypedDict)" or "Point2D=TypedDict(...)" which are equivalent..?
<arigato>
will only add to the newbie confusion of "subclass" vs "instance"
<cfbolz>
arigato: also "instances" of such a TypedDict are just dicts
<arigato>
ah, real dicts?
<cfbolz>
yes
<cfbolz>
... but they would be a good usecase for the json dict strategy
<arigato>
yes
<arigato>
so it's a built-in example of: A is a subclass of B, A() is a dict, B()() is a dict
<cfbolz>
yes, super strange
<cfbolz>
arigato: so the gcc bug was them not using their integer abstract domain correctly?
<arigato>
I think so, but I don't understand any of the gcc internals
<cfbolz>
me neither, really
<cfbolz>
sounds scary all
<arigato>
I hope it's a proper fix and not just "we see a bug, by whacking there it doesn't show up any more"---I trust it's fine but I cannot check
<cfbolz>
arigato: if it's really the integer domain, it's notoriously hard
<arigato>
cpus should only have the unlimited bigints, never something as messy as N-bit integers
<arigato>
I'm sure it can be designed in the spirit of complex modern Intel-like CPUs, and sold as a speed benefit because it can compress smaller integers into less than 4/8 bytes
<arigato>
burning even more electricity for a little bit more speed
<cfbolz>
arigato: hah
<cfbolz>
then compilers will start proving complex number theoretic properties for you
<arigato>
yay!
simpson has joined #pypy
BPL has joined #pypy
tsaka__ has joined #pypy
<mattip>
arigato: around?
<arigato>
mattip: yes
<mattip>
about separating bytecode file names, cffi so names, and c-extestion file names: any idea how to do that?
<arigato>
I think we need someone else's opinion about producing two different patterns of .so files
<arigato>
it's probably fine
<arigato>
but I really try to stay away from distribution issues so I don't know
jvesely has quit [Quit: jvesely]
<mattip>
cffi modules are tied to the regular import process, and so should follow the same syntax as c-extension modules. I don't see how to separate them
<mattip>
ahh, cffi already has a _set_py_limited_api() function, with the comment
<mattip>
"Setuptools takes care of ignoring the flag on Python 2 and PyPy"
kbtr has quit [Remote host closed the connection]
forgottenone has joined #pypy
<mattip>
which boils down to pypy3 not putting '.abi3.so' into importlib.machinery.EXTENSION_SUFFIXES
<mattip>
python2 and pypy2 are a lost cause: it will always use the non-py_limited_abi name
<tumbleweed>
mattip: what problem are you trying to solve?
<tumbleweed>
without a 2.8, limited_abi seems irreleveant to python 2
<mattip>
currently when we build the _audioop cffi module, the name is _audioop_cffi.pypy-41.so on pypy2.7 v7.2
<mattip>
and when we build a c-api module the name is the same: _dummy.pypy-41.so
<tumbleweed>
what's the issue with that?
<mattip>
which has remained constant across too many versions of pypy, so c-api modules built with 7.2 may not work on earlier version
<tumbleweed>
ah, right
<mattip>
we should be using a full PEP 425 tag, like on pypy3
<tumbleweed>
so you want stable ABI for cffi modules
<tumbleweed>
but want to be able to bump DEFAULT_SOABI for c-api
<mattip>
yes, even on pypy2
<tumbleweed>
I had wondered why DEFAULT_SOABI was never being bumped any more
<mattip>
it **is** being bumped on pypy3, but not on pypy2
<tumbleweed>
I can imagine hacks to make this work, but they'd break tools that expect cpython like behavior
* mattip
off to a meeting, back in two hours
<tumbleweed>
arigato: BTW, I applied your workaround to the gcc bug. Works well for pypy2, but for 3, getting some interesting test failures that look like more JIT weirdness https://paste.debian.net/1109365/ (the offending line is: return f(*args, **kwds)
<mattip>
with cpython3.6 and cffi 1.12.3 creates a non-limited_api so _example.cpython-36m-x86_64-linux-gnu.so
<mattip>
so at least it seems pypy3 is consistent with cpython3
<mattip>
thanks for helping work through this
jvesely has quit [Quit: jvesely]
jvesely has joined #pypy
<tumbleweed>
np. I don't think we're that much closer to solutions though :P
firespeaker has quit [Quit: Leaving.]
<mattip>
well, there really is no solution for python2 without hacks
lritter has quit [Ping timeout: 246 seconds]
CrazyPython has joined #pypy
Rhy0lite has quit [Quit: Leaving]
CrazyPython has quit [Remote host closed the connection]
<tumbleweed>
I think you'd need buy-in from pypa to introduce a new mechanism. And given the EOL of python2, it's hard to imagine people putting work into that
jvesely has quit [Quit: jvesely]
CrazyPython has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
njs has joined #pypy
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
jvesely has joined #pypy
CrazyPython has quit [Remote host closed the connection]