<njs>
anyone have any guesses about why calling gc.collect() repeatedly could fail to collect an unreachable object, BUT ONLY if running with coverage enabled?
<njs>
oh gods, is this another interaction between tracing and fast locals? I'm doing 'del e; print(locals())' and with coverage enabled, the print shows 'e' as still present
Atque has quit [Quit: ...]
slav0nic has joined #pypy
Atque has joined #pypy
<cfbolz>
njs: hey :-)
<cfbolz>
in pypy or in cpython?
nimaje has quit [Quit: WeeChat 3.3]
nimaje has joined #pypy
Dejan has joined #pypy
Atque has quit [Quit: ...]
Atque has joined #pypy
Dejan has quit [Quit: Leaving]
<mattip>
we should really upgrade our coverage support since the first place many library developers meet PyPy is when running CI, and many of them turn on coverage by default
<mattip>
so they get a bad impression about pypy from the very first CI run
<mattip>
slow, buggy, ...
<mattip>
cfbolz: there are a couple of at_exit tests failing in test_threading
<njs>
after the 'del e' on line 720, if you add a 'print(locals())' then 'e' is still present, iff running on pypy under coverage
<njs>
I suspect it has to do somehow with the call to `await force_receive_loop_to_start()` capturing 'e' in a cell, even though that frame is dead and gone before the 'del e'
infernix has joined #pypy
greedom has quit [Read error: Connection reset by peer]
greedom has joined #pypy
<mattip>
we never implemented posix_spawn for py3.8