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
mwhudson has quit [Remote host closed the connection]
* arigo
still trying to figure out why cpyext tests fail on his machine and not on the buildslaves
<arigo>
...turns out to be because of a different gcc version
<arigo>
it seems that very recent gcc's make the cpyext tests fail
<arigo>
we define by mistake a few global variables in two .c files
<arigo>
I have no clue what older versions of gcc do with that
todda7 has quit [Ping timeout: 246 seconds]
dddddd has quit [Ping timeout: 258 seconds]
<mattip>
arigo: +1
<arigo>
fixed
todda7 has joined #pypy
BPL has joined #pypy
<arigo>
(to clarify, it seems it's a problem of the linker: the exact behavior of defining several times the same variable in undefined, and older versions of ld would just make a union. Newer versions seem to have changed that)
_cipher has joined #pypy
_cipher has quit [Quit: Leaving]
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
xcm has quit [Killed (card.freenode.net (Nickname regained by services))]
xcm has joined #pypy
thrnciar has quit [Remote host closed the connection]
<antocuni>
arigo: I think that commit 338b6c45ed55 is buggy: if the GC runs in the middle of "for wr in self.data.values", the size of the dictionary changes during the for loop
<antocuni>
I think we have two solutions: 1) simply use list(self.data.values())
<antocuni>
2) use gc.disable()/gc.enable() around the for loop
<antocuni>
do you (or anyone else) have opinions?
<antocuni>
also: do we have any existing testing machinery which could help to reproduce this bug?
<antocuni>
(i.e., something which we can use to spawn an external pypy process and setting env variables)
<antocuni>
mattip: what is the status of the py3.6/py3.7 branches? Should I commit the fix to py3.6 or py3.7, or both? Do we regularly merge one into the other?
<antocuni>
also, I wonder whether we should maybe have a branch called "3.x" instead of one for each minor version (or maybe whether we should call it "default" :))
<mattip>
so it is equivalent to "PYTHONMALLOC=debug python3 -W default -X faulthandler"
<mattip>
I don't think PYTHONMALLOC=debug actually does anything on PyPy, but the other two might be useful, especially if people are using -X dev
dddddd has joined #pypy
<mattip>
so my vote would be "if it's not to hard, we should do it"
<YannickJadoul>
Alright, then I'll try to get as close as possible
<YannickJadoul>
These kinds of things are just in app_main.py? I tend to get a bit confused by the amount of "main"-related files in PyPy
<cfbolz>
YannickJadoul: yeah, app_main should be the place
<YannickJadoul>
Thanks!
<YannickJadoul>
And what about pyinteractive? That seems to have its own cmdline options?
<cfbolz>
YannickJadoul: we don't care about that, imo
<YannickJadoul>
OK. I had just found that you can run some of the CPython tests through that. But maybe it's not the correct way :D
<mattip>
that is for running PyPy over CPython2 in an untranslated mode. You really have to struggle to get it to work, and it usually is not worth the effort
thrnciar has quit [Remote host closed the connection]
thrnciar has joined #pypy
<mattip>
numpy seems to work (with d76bda509e9d) on py3.7
<antocuni>
mattip: about pickle5: if I understand it correctly, we will need to implement it anyway for py3.8, right? Then probably the easiest way is to implement it for py3.7 already (or even py3.6, maybe), so the "backport" can be as easy as "import pickle"
thrnciar_ has quit [Ping timeout: 256 seconds]
Dejan has joined #pypy
Dejan has joined #pypy
Dejan has quit [Changing host]
jcea has joined #pypy
todda7 has quit [Ping timeout: 258 seconds]
_cipher has joined #pypy
todda7 has joined #pypy
oberstet has quit [Remote host closed the connection]
todda7 has quit [Ping timeout: 260 seconds]
asmeurer has joined #pypy
YannickJadoul has quit [Ping timeout: 240 seconds]
YannickJadoul has joined #pypy
<arigo>
antocuni: thanks for the fix. I guess I'm still not used to "dict.values()" returning an iterator that explodes if the dictionary changes
<arigo>
antocuni: actually I suspect your fix is not 100% crash-proof: the gc could run between self.data.values() and list()
<arigo>
ah no, maybe it's still fine: .values() returns an iterable, and only list() turns it into an iterator and immediately exhausts it
<arigo>
...aaand no, it's not, because list() has internally its own jitdriver
<arigo>
...maybe it's still fine, because even if the GC runs randomly, calling back to app-level code should be delayed until the next python bytecode boundary
<arigo>
I think that should still be the case even if the JIT comes along and compiles stuff
<antocuni>
arigo: ah indeed, I didn't think about the GC running during the list() call. I think it's fine because as you say the weakref callbacks will be called later, although it's a bit fragile
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<arigo>
not really more than calling the Python 2 ".values()" method (which doesn't exist but let's assume it did)
<antocuni>
indeed
<arigo>
because even during a call to the python 2 .values(), the GC runs randomly to grow the resulting list
<arigo>
also, remember that unless I'm wrong, the original Python code was buggy on CPython too (it works only most of the time)
<antocuni>
I think that for now I am happy to just fix the error I saw in the real world :)
asmeurer has quit [Quit: asmeurer]
thrnciar_ has joined #pypy
lritter has quit [Quit: Leaving]
thrnciar_ has quit [Ping timeout: 256 seconds]
thrnciar_ has joined #pypy
_cipher has left #pypy ["Leaving"]
jacob22_ has quit [Read error: Connection reset by peer]