cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
mattip has quit [Ping timeout: 264 seconds]
mattip has joined #pypy
<mattip> darn. Even this segfaults on the release since binary compatibility is broken: 'pypy -m pip install numpy; pypy -c "import numpy; numpy.test()"'
<mattip> I added a numpy build to that shows the problem :(
<mattip> mgorny, tumbleweed: is there a way to re-release 7.3.6 with a backward compatible API?
<mgorny> mattip: i'd make it 7.3.7 to avoid confusion
<mgorny> and add a big warning to 7.3.6
<mgorny> that said, are we talking about pypy3.8 too or just 2.7/3.7?
<mgorny> (i probably didn't notice because i went straight for 3.8, so total rebuild was expected anyway)
<arigato> mattip: not sure to see the point, just do a 7.4.0 and don't spend time reverting carefully some bits
Atque has joined #pypy
<mattip> arigato: yeah, it appears we will have to
<mattip> but then this means projects like cryptography will have to release wheels for both pp37-pypy73 and pp37-pypy74
<mattip> mgorny: pypy3.8 would be OK to move to 7.4.0 since it is too early for wheels to have appeared with pp38-pypy73
<mgorny> mattip: yeah, i'd prefer not to have to rebuild everything there ;-)
<mgorny> i.e. leave the new ABI for pypy38 as-is
<arigato> is the ultimate goal of pypy3.7 to continue being updated for a while, or just dropped?
<arigato> if dropped, then I see the point of wanting to at least not change its C ABI right now
<mattip> arigato: correct. If progess on py3.9 moves quickly, and we do not see too many problems with py3.8, I will propose that the bugfix release be the last release of py3.7
<arigato> OK
<mattip> so it seems I should release pypy3.7 v7.3.7 and pypy3.8 v7.4.0. Complicated
<arigato> you could also say that older pypy3.8 < 7.3.6 were beta anyway, and not care about wheels built with them
<arigato> and only release pypy3.7 7.3.7
<mattip> well, NumPy for instance is releasing in 6 weeks.
<mattip> If we declare 7.3.6 broken (which it is) and do not release a pypy3.8 v7.4.0, then they will not release a pypy3.8 binary wheel at all
<arigato> no, I mean, pypy3.8 7.3.6 is not broken, if nobody used the older pypy3.8 < 7.3.6 because they were beta
<arigato> if I'm wrong about that, then fine :-)
<mattip> you are not wrong, we could continue calling the version "7.3.x" as long as we keep pypy3.7 with the older, 7.3.5, ABI
<mattip> we never released a pypy3.8 < 7.3.6
otisolsen70 has joined #pypy
Atque has quit [Quit: ...]
Atque has joined #pypy
Atque has quit [Quit: ...]
greedom has joined #pypy
<cfbolz> mattip: hm, complicated
<cfbolz> mattip: are there any ABI changes we held back but like to do at some point?
<mattip> I would like to get our PyThreadState struct more inline with CPython,
<mattip> and design a stable API like CPython's abi3
<mattip> but there are none we held back from the release
Atque has joined #pypy
<cfbolz> mattip: right
<cfbolz> Anyway, seems mgorny has pretty reasonable arguments
greedom has quit [Remote host closed the connection]
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
Gustavo6046 has quit [Read error: Connection reset by peer]
slav0nic has joined #pypy
<mattip> ok, so we stick with 7.3.7 (for the c-api reversion on py3.7) and the next real release will be 7.3.8
<mattip> unless we decide it is worth the price to break ABI compatibility for PyThreadState or some kind of stable API
Julian has joined #pypy
lritter has joined #pypy
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
<cfbolz> mattip: thanks for dealing with this
<tumbleweed> doesn't matter to me (because we still don't build anything against pypy3.x in Debian)
lritter has quit [Quit: Leaving]
ronan has quit [Quit: Leaving]
Gustavo6046 has joined #pypy
Atque has quit [Quit: ...]
otisolsen70 has quit [Quit: Leaving]
Julian has quit [Quit: leaving]
<mattip> tumbleweed: thanks
<cfbolz> making progress with 3.9, very slowly
<cfbolz> trying to get the stdlib tests to run again
<Corbin> I'm trying to link against a single-file library ( and putting it in the includes seems not to work.
<Corbin> My rffi declaration is and translation works, but the C compiler complains "undefined reference to `stbi_write_png'"
<Corbin> pre_include_bits=["#define STB_IMAGE_WRITE_IMPLEMENTATION"] helps a little? This gets the STB library to define its procedures, but it defines them multiple times, so now I get "multiple definition of `stbi_write_png'"
<mattip> cfbolz: we should try to get some of our changes to stdlib into upstream, so the merge is easier
<cfbolz> mattip: actually I was pleasantly surprised that quite a few of our changes were in 3.9
<mattip> Corbin: can you try to mimic an example use of stb_image_write.h somewhere so you know what has to be define/undefined?
<cfbolz> mattip: eg almost all gc.collects in tests
<mattip> cool
<Corbin> mattip: I think I got it. I used a separate module which effectively just becomes the instantiated header; translates.
<mattip> +1
<Corbin> And it produces a PNG! Progress. Sorry for rubber-ducking.
<mattip> :)
nimaje has quit [Ping timeout: 268 seconds]
slav0nic has quit [Ping timeout: 260 seconds]
nimaje has joined #pypy
Gustavo6046 has quit [Ping timeout: 245 seconds]
Gustavo6046 has joined #pypy
Gustavo6046 has quit [Read error: Connection reset by peer]
Gustavo6046 has joined #pypy
[Arfrever] has quit [Quit: leaving]