cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
alicetries has joined #pypy
alice has left #pypy [#pypy]
epony has joined #pypy
Guest96 has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest96 has joined #pypy
_0az3 has joined #pypy
<arigo> mattip: putting tp_pypy_flags at the end of PyTypeObject was asking for the exact kind of troubles you're now in
<arigo> I would suggest removing tp_pypy_flags completely, otherwise you're going to have the same problem every time CPython adds anything to PyTypeObject, and finding a different hack
<arigo> in this case, maybe using a #define to check if sizeof(long) > 4 and if so using a flag in tp_flags that is beyond the 32 bits? and on 32-bit machines, too bad, you don't have that very minor optimization
<mattip> then we also need to ask cython to remove the code to add tp_pypy_flags to the PyTypeObject
<arigo> yes, I have no idea why they added this code in the first place
<arigo> also, I may be saying nonsense, but I *think* that already-compiled wheels should continue to work fine?
<arigo> they are basically declaring a static PyTypeObject which ends in a zero, which used to be tp_pypy_flags but which will now be interpreted as tp_vectorcall, and zero is still the correct value by default
<arigo> unless they were actually using the constant that says "I'm a float subclass", which I doubt
<arigo> (maybe in numpy?)
<mattip> I think the problem is using an older c-extension module with a newer PyPy, since at some point we will call _type_realize
<mattip> to create the w_obj from the pyobj
<mattip> when we check the c_tp_pypy_flags we will be reading off the end of the struct, no?
<arigo> this is unrelated to tp_pypy_flags, right?
<arigo> ah I see what you mean
<mattip> it is related to them in that we use a computed offset to look at c_tp_pypy_flags
<arigo> well if the question is only about newer versions of pypy, then you can change the code there---for example by removing tp_pypy_flags as I suggested above
<mattip> right, sounds correct
<mattip> cool
<arigo> the "proper" answer is probably to have some version info, say in the PyTPFLAGS_DEFAULT
<arigo> then you can check the version of this particular C extension module and do different things
<arigo> (if needed)
<mattip> theoretically that is the PYPY_VERSION, which should reflect the ABI, but we are trying not to change the DEFAULT_SOABI_BASE
<mattip> from pypy/module/imp/importing
<arigo> yes, I meant more like PyTPFLAGS_HAVE_GC or this kind of flag: PyTPFLAGS_DOESNT_HAVE_PYPY_FLAGS_ANY_MORE? but again it's not needed here
<mattip> right
<arigo> an old extension module already compiled might use the macro _PyPy_Type_FastSubclass which will now read the tp_vector field for types produced by pypy
<arigo> still, that's fine because the checked flag value is 1, and pointers to functions are typically not odd numbers
<arigo> (no I know it doesn't make sense, I'm just saying that it might work anyway)
<mattip> so far no c-extension module I could find actually uses that field, I think it is used internally by cpython but not by pypy
<arigo> ah ok
<mattip> sizeof(long) == 4 on windows64, but there are some other unused values: for instance 1<<23.
<mattip> Perhaps we could ask CPython to "reserve" it for us
<mattip> we can definitely use it on py3.8 to work around the problem
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
<arigo> pretty sure you can use a SIGNED without breaking anything, because on win64 it is between two pointers so alignment makes the unused 4 bytes wasted anyway
<krono> You could put pypy specific stuff right _before_ the actual PyTypeObject… just be sure remember that for memory management stuff…
<mattip> krono: the crux of the problem is we missed adding a field when we released PyPy3.8,
<mattip> so we need to do something for that branch that can support both versions
slav0nic has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
greedom has quit [Remote host closed the connection]
<krono> i see, complicated setting
Guest96 has joined #pypy
x88x88x has quit [Read error: Connection reset by peer]
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest96 has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest96 has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest96 has joined #pypy
greedom has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
<mattip> hmm, so CPython rejected the idea of adding a FLOAT_SUBCLASS flag, saying that
<mattip> even if the flags field was 64-bit they would still not add it
<mattip> so I guess we will keep tp_pypy_flags for 3.9+
Guest96 has joined #pypy
greedom has quit []
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slav0nic has quit [Ping timeout: 260 seconds]