cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "the modern world where network packets and compiler optimizations are effectively hostile"
<kenaan>
mjacob py3.6 1c770e1ebaa0 /pypy/interpreter/astcompiler/: Test and fix: a global declaration after an assignment with the same name is now a SyntaxError instead of only a war...
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
<njs>
fijal: the question was whether there are currently any binary wheels for pypy on pypi, and how big the disruption would be if pypy started reporting a more accurate abi tag
vkirilichev has quit [Remote host closed the connection]
<antocuni>
njs: AFAIK, nobody binary wheels for pypy has been used only in private indexes so far
* fijal
is getting bitten by assert rewriting
<njs>
antocuni: yes, I was saying that I checked the bigquery pypi download logs and none of the files downloaded so far in july had the string "pp41" in their name
<antocuni>
njs: moreover, I tried to play a bit with wheels; I see that by default, I get wheels with this name: netifaces-0.10.6-pp258-pypy_41-linux_x86_64.whl
<antocuni>
which I think it means: pypy2 version 5.8, pypy_41 ABI tag
<njs>
ah, so pp41 was the wrong thing anyway
<njs>
yeah
<njs>
I was wondering about that
<fijal>
arigato: eh, may I complain that I hacve "assert False" that's clearly hit and got eaten by py.test?
<antocuni>
so, if the pypy version is included in the name, the ABI tag is redundant, isn't it?
<njs>
I guess basically the problem is that no-one has thought about this at all for pypy so it just makes zero sense :-)
<antocuni>
yes :)
<ronan>
fijal: what are you doing?
<fijal>
ronan: writing tests
<antocuni>
well, at least for now it means that it is not horribly broken, because wheels for a specific version are not used by other ones, so things work
<fijal>
or what do you mean?
<ronan>
fijal: yes, but where?
<njs>
for cpython something like cp27-cp27mu is somewhat meaningful, because "cp27" means "cpython 2.7", and then "cp27mu" means "with pymalloc and 4-byte unicode support"
vkirilichev has quit [Remote host closed the connection]
<antocuni>
I think that the pypy plan at some point is to stabilize the cpyext ABI, so in theory when we do the extensions will be cross-compatible between versions
<fijal>
heh good luck
<antocuni>
so in that case we will probably need something like pp2-pypy_59 or so
<njs>
antocuni: really I think it would make more sense if it were py27-cp27mu, basically meaning "the python parts need 2.7, and the binary parts needs the cpython 2.7 pymalloc+proper-unicode C ABI"
<njs>
antocuni: and possibly that's what would make most sense for pypy, regardless of whether cpython wants to go that way
<njs>
antocuni: regarding manylinux2, please do make it happen :-) everyone agrees it's needed, it's pretty straightforward, but everyone in packaging is *super* overloaded so it's been hanging around waiting for someone to volunteer
rokujyouhitoma has joined #pypy
tormoz has quit [Remote host closed the connection]
* antocuni
runs away scaried :)
<njs>
antocuni: no srsly, it's like 10x less scary than anything involving pypy internals, I promise :-)
<antocuni>
yeah sure but jokes apart I'm overloaded as well :(
<njs>
(if anyone ever wanted a PEP with their name on it then this is an extremely easy case -- the PEP only needs to be like 20 lines long and is guaranteed to be accepted :-))
<ronan>
fijal: that looks correct
<fijal>
ronan: "that" being?
<ronan>
fijal: your diff
<antocuni>
njs: why do you need manylinux3 as well?
<fijal>
ronan: as in, should really hit assert False somewhere in the code?
rokujyouhitoma has quit [Ping timeout: 260 seconds]
<njs>
antocuni: some people want it for newer C++ and powerpc and stuff, and it's literally the same thing with s/centos6/centos7/g, so it makes sense to define them both at the same time
<ronan>
fijal: I haven't seen any assert False
<antocuni>
and I suppose that the only difference is that you will be able to install manylinux2 on more distros than manylinux3?
<njs>
antocuni: yeah
<antocuni>
I see
<fijal>
ronan: it should hit one in BinOp.compile
<fijal>
if you add an xxx before, you get it
<njs>
(in practice, even centos7 is older than almost any other distro's LTS, I think the difference is that manylinux2 can be installed on centos6 and debian oldstable, or something silly like that)
<antocuni>
so, why not simply base manylinux2 on centos7?
<njs>
antocuni: because people do run centos6
<njs>
antocuni: for some reason
<antocuni>
ah, ok
<njs>
antocuni: honestly I wish they would stop but this is the path of less resistance :-)
<fijal>
ronan: I mean I know how to fix it, but I'm worried about pytest
<fijal>
how is assert False ignored?
<antocuni>
yeah sure, I suppose that dealing with people is not easy :)
<antocuni>
njs: how will pip behave when it will find wheels for manylinux{1,2,3} at once? Will it install the highest available one?
<fijal>
ronan: do you know how it works? bytecode looks legit
<njs>
antocuni: IIRC pip internally has a list of which tags are preferred over others, so yeah, we can put manylinux3 > manylinux2 > manylinux1
<antocuni>
ok
<ronan>
fijal: that sounds very weird, bytecode shouldn't be rewritten outside test files
<fijal>
ronan: ok?
<fijal>
ah
<fijal>
ok.... python strikes back
<fijal>
class False()
mattip has joined #pypy
<ronan>
aaahh
<njs>
fijal: that's a syntax error on python 3 :-)
<fijal>
good :)
rmariano has joined #pypy
vkirilichev has quit [Remote host closed the connection]
mattip has left #pypy [#pypy]
ronan has quit [Ping timeout: 260 seconds]
forgottenone has quit [Ping timeout: 240 seconds]
ronan has joined #pypy
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
Tiberium has quit [Remote host closed the connection]
Tiberium has joined #pypy
rokujyouhitoma has joined #pypy
Tiberium has quit [Remote host closed the connection]
Tiberium has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
Tiberium has quit [Remote host closed the connection]
Tiberium has joined #pypy
ronan has quit [Ping timeout: 260 seconds]
arigato has quit [Quit: Leaving]
rokujyouhitoma has joined #pypy
asmeurer__ has joined #pypy
rokujyouhitoma has quit [Ping timeout: 255 seconds]
asmeurer__ has quit [Quit: asmeurer__]
forgottenone has quit [Ping timeout: 240 seconds]
mattip has joined #pypy
ronan has joined #pypy
<kenaan>
rlamy cpyext-leakchecking 0d18cd6d4afc /pypy/module/cpyext/typeobject.py: Temporarily disable tp_mro and tp_dict slots to avoid ref cycles that prevent types from being collected
<mattip>
ronan: nice catch
<ronan>
mattip: the trouble is that I don't know how to support these slots without creating uncollectable cycles
<ronan>
also, I'm not sure that this was really an issue after translation
ronan has quit [Read error: Connection reset by peer]
ronan has joined #pypy
<mattip>
ronan: a hacky way would be to release data when refcount goes to 0/REFCOUNT_FROM_PYPY in decref in pyobject.py,
<mattip>
and for after translation, we could write a -A test
<ronan>
mattip: the whole issue is that the refcount does not go to 0/REFCOUNT_FROM_PYPY
* mattip
actually looking at cpyext-leakchecking
<ronan>
basically any cycle that crosses the C/RPython boundary is uncollectable
<ronan>
*that is not wholly on the RPython side, actually
<mattip>
naively I would suggest somehow making them weakrefs, dunno if that is possible
<mattip>
or some kind of new weakref?
<mattip>
but the first step would be to see if this happens after translation
<ronan>
I think we just need to stick the W_TupleObject in some RPython-visible place
<ronan>
but it seems wasteful to add a w_mro to all types, just for cpyext
rokujyouhitoma has quit [Ping timeout: 260 seconds]
yuyichao_ has quit [Read error: Connection reset by peer]
yuyichao has joined #pypy
rmariano has joined #pypy
Tiberium has quit [Remote host closed the connection]
<mattip>
ronan: but by that logic, the w_dict should not cause a cycle since it *is* stored on the w_obj
<mattip>
or maybe I am not thinking deep enough
<mattip>
ahh, maybe it is not the actual w_obj.w_dict
<mattip>
rather the rterned value from w)obj.get_dict(space)
antocuni has quit [Ping timeout: 246 seconds]
<ronan>
yes, it's created on the fly
<ronan>
TBH, I don't fully understand the issue, but RPython objects that are kept alive by an incref cannot be collected unless the refcount drops to 0