cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<tsutsumi1>
It looks like there's often a "space" variable used to do things like log warnings, but one isn't passed into the method. I'm also worried that rpython doesn't support warnings
<tsutsumi1>
does someone have an idea?
raynold has quit [Quit: Connection closed for inactivity]
tsutsumi1 has quit [Ping timeout: 240 seconds]
Garen has quit [Read error: Connection reset by peer]
<karanlyons>
Hey all, this might be a PyPy bug or I might be stupid but either way I kinda need someone who knows better than me to chime in: https://dpaste.de/BMbm
<karanlyons>
Basically it looks like subprocesses in PyPy spawn with the same (?) event loop of their parent, in contrast to the behavior I see in CPython.
exarkun has quit [Read error: Connection reset by peer]
exarkun has joined #pypy
asmeurer_ has quit [Quit: asmeurer_]
<karanlyons>
It's possible this is a preexisting bug from asyncio in CPython for which the bugfix was never ported: https://bugs.python.org/issue22087
<karanlyons>
My CPython's asyncio.events has checks for the pid when returning the event loop. These checks are not present in PyPy's.
<arigato>
well done to track it down!
<arigato>
which CPython version is that exactly?
<karanlyons>
So the good news is it's easily correctable especially since this is all python, I think.
<karanlyons>
I don't have a good way of working out when this change happened in CPython in terms of releases.
<arigato>
but you're looking at which version? pypy3 uses the stdlib from CPython 3.5.3
<karanlyons>
It's possible PyPy is exhibiting "correct" behavior for the version of CPython it's meant to be compatible with.
<karanlyons>
Yeah, I think this fix might have only landed in 3.6.
<arigato>
ah
<karanlyons>
Not totally sure, though.
<karanlyons>
Either way you can just manually clear the loop and instantiate a new one in the child proc.
<karanlyons>
Well, this has been yet another journey of discovery off the rather unworn path towards what I'm actually supposed to be doing :D
fijal_ is now known as fijal
<arigato>
ah, cpython's 3.5 head has got checks for the pid, but not cpython's v3.5.3 tag
<fijal>
arigato: can you send me a pm?
<fijal>
testing if my IRCcloud is still screwed
<karanlyons>
arigato: Yeah, the tags in the repo are confusing me a bit as to when this actually landed in a release.
<fijal>
ok thanks
<karanlyons>
But I'm seeing 3.6 as well, so I'm just going to assume it wasn't really fixed till then.
<arigato>
I think it's in v3.5.4 but not v3.5.3
<arigato>
ok "good"
<karanlyons>
Missed it by 0.0.1.
<karanlyons>
So close
<arigato>
obviously, we should update to the latest 3.5.x at some point
<arigato>
hopefully it's less of a mess than the v3.5.1 - 3.5.2
<arigato>
which changed many things
<karanlyons>
Isn't 3.6 in the works too? I admit I don't actually brush up on dev process of either CPython or PyPy until I've managed to break them somehow.
<karanlyons>
s/process/progress/
<arigato>
:-)
<arigato>
yes, but 3.6 is just started and will take a while
<karanlyons>
Well this is all good to hear. My bug rate on PyPy is still only 1, but that's also pretty great :)
<karanlyons>
I think you helped with that one too, ages ago.
<karanlyons>
You had it patched before I was even finished cloning the repo.
<arigato>
says something about bitbucket... :-)
<karanlyons>
Haha, yeah.
<karanlyons>
Well, now I must sleep, but thanks for suffering me quietly :P
<arigato>
:-)
<arigato>
see you
* arigato
attempts to port RevDB to the latest pypy2
<kenaan>
arigo reverse-debugger-updated 2b804a3bfea0 /rpython/rtyper/: Test fixes
<kenaan>
arigo reverse-debugger-updated 2fe38255fdb8 /rpython/rtyper/lltypesystem/: Fix some tests
jaffachief has joined #pypy
<kenaan>
arigo reverse-debugger-updated 4a2a458b4728 /: More diff reduction
<kenaan>
arigo reverse-debugger-updated 679c88232aae /rpython/rlib/objectmodel.py: Fix some tests that failed with "trying to change a frozen option object"
jaffachief has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
forgottenone has joined #pypy
antocuni has quit [Ping timeout: 260 seconds]
<kenaan>
arigo default 0088ece5635b /pypy/module/cpyext/: Make this a pointer instead of a Py_ssize_t. Why not, and reduces the diff from reverse-debugger.
jamesaxl has quit [Ping timeout: 240 seconds]
<kenaan>
arigo reverse-debugger-updated 5fc00945551a /: RPython fix: we can't pass around module objects, they must be fully resolved by the flow graph
<antocuni>
as you can see, it's not only the first step of sweeping which takes lot of time
<antocuni>
it's also the last step of marking
<antocuni>
also, the chart is still weird: I added some more logging: the first 4 yellow points are all SWEEPING steps which free raw objects
<antocuni>
the first 3 free 140434 objects each (the maximum allowed), while the last one frees the remaining 57890
<cfbolz>
ronan: huh? no?
<antocuni>
so, I'd expect the first 3 to be more or less equally slow, and then the last to be faster. However, the chart shows that it's only the first to be very slow
<ronan>
cfbolz: check the code for assert reinterpretation...
<cfbolz>
ronan: ok, but only if they fail then?
<ronan>
yes
<cfbolz>
right
<antocuni>
cfbolz: my GC analysis might be interesting for you as well
<cfbolz>
antocuni: sorry, I don't know much about incminimark
<arigato>
note that the syntax "[] = []" works already in python 2.7
<cfbolz>
arigato: so it's just tuples that are new?
<arigato>
yes
<cfbolz>
ok
<arigato>
I'd guess the SyntaxError is because of the same mess we have now
<cfbolz>
'yay'
<arigato>
the peephole optimizer would replace it with "constant empty tuple" and then obscure failres
<arigato>
...failures
<kenaan>
cfbolz py3.6-wordcode 72505716f39c /pypy/interpreter/pycode.py: we can't use _from_code anymore either
<kenaan>
cfbolz py3.6-wordcode a890ba3fdb85 /pypy/: use _from_code less often (it's still in the apptest support, but I'll ignore that for now)
<antocuni>
cfbolz: sure, but I'm a bit clueless right now :-/, that's why I was basically thinking alound in the channel
<antocuni>
my only theory so far is that for some reason we have a raw_malloc()/raw_free pattern which is not handled very well by the libc, so the first N frees() are slower than the rest
<antocuni>
although it's a bit fragile as a theory... like when you blame the compiler for a segfault :)
<antocuni>
moreover, I didn't manage to reproduce the sweeping peak with a small script so far, I see it only in production
<antocuni>
(but I can easily reproduce the peak in the last phase of marking, which is probably something else we need to fix)
<cfbolz>
antocuni: if libc is the problem you should try another malloc
tayfun26 has quit [Quit: tayfun26]
lritter has joined #pypy
lritter has quit [Client Quit]
<antocuni>
cfbolz: good point
sthalik has quit [Quit: Alwyzon, cloud-powered IRC client and bouncer - http://alwyzon.com/]