<mattip>
is there a concise and convincing answer I can give?
<mattip>
do we respect the 'generation' argument to gc.collect ?
<arigato>
there's a very technical reason, do you want to hear it?
<arigato>
it's because CPython makes strange guarantees about the order in which __del__ methods are called
<arigato>
as a result, if we have an object with __del__ methods pointing to more objects with __del__ methods, we can only call the first one after a full GC, and we need to wait until the next GCs to call the other ones
<mattip>
good enough, thanks
<arigato>
when you write gc.collect(); gc.collect(); gc.collect() then you're actually letting __del__ methods run in the semicolons
<energizer>
arigato: why three calls in particular?
<mattip>
two may have been enough, I threw an extra in just to be sure
<arigato>
this note is worded in a way that says "everything is fine", but is actually saying "in some cases deallocators will still be called multiple times so well"
<mattip>
yes, too many negative clauses cloud the problem
<cfbolz>
Annoying
<arigato>
and if somebody answers "but regular __del__ methods on user-defined classes will only be called once", I answer "yes, except in one case, because it is possible to make a class whose instances don't have the GC header internally"
<cfbolz>
arigato: uh, how?
<arigato>
class X(object): __slots__=[]
<cfbolz>
Of course
<cfbolz>
Way too much magic
<arigato>
essential optimization!
darkman66 has quit [Quit: Leaving...]
<cfbolz>
Slots are just such a sad story on all levels
lazka has quit [Remote host closed the connection]
Alex_Gaynor has quit [Ping timeout: 252 seconds]
Alex_Gaynor has joined #pypy
<mattip>
EWDurbin: ping speed.pypy.org now gives codespeed.nyc1.psf.io, but https://speed.pypy.org is saying "connection refused"
<mattip>
wrong channel
antocuni has joined #pypy
airwolf-irc has joined #pypy
<mattip>
ok, wrote a docstring that I think captures it
<antocuni>
if I call "foo", it tops at 198 bridges
<antocuni>
if I call "bar", it tops at 498; I would expect the very same number
<antocuni>
what's happening?
adamholmberg has joined #pypy
<antocuni>
oh no, it's different; if I let it running for more, foo arrives at 495
<antocuni>
but the question remain: why "bar" compiles bridges so quickly, while "foo" takes much more to warm up?
<fijal>
arigato: ok, so I just redo that
* fijal
fighting with calls
<antocuni>
also, why ~500? I'd expect ~256
<antocuni>
final question: if I put 16 lines "if myrandom.random(): ..." instead of 8, the total number of bridges tops out at 514, no matter how long I let it running. I'd expect it to genereate ~2**16 bridges
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
<alawrence>
antocuni: Is there some magic contained within pypy?
<antocuni>
alawrence: what do you mean?
<Alex_Gaynor>
No magic, just sufficiently advanced technology
<alawrence>
antocuni: The code has a layer of abstraction that hides a lot of complicated wizardry that goes on underneath to make it work.
<antocuni>
so?
<alawrence>
antocuni: I was just asking if that was the case with pypy.
<antocuni>
well yes, pypy contains some complex technology which is abstracted away from the final user
<antocuni>
unsure how/if it relates with my question about the number of bridges produced
<simpson>
alawrence: Hm. That'd be like every compiler, though, right? We regularly (in, say, #proglangdesign) demystify compiler design, but without instruction, it can seem like parsers, optimizers, and code emitters are magic.
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
<alawrence>
simpson: Yes I would expect that every compiler does this. I am not sure what a compiler would look like if it didn't employ some layer of abstraction.
<alawrence>
simpson: There was an element of tongue in cheek with my previous comments but I would be grateful to learn more about the internals of PyPy. I think it will take sometime before I understand what the jit compiler is doing exactly.
<fijal>
arigato: do you feel like helping me understand the complicated logic in arm which arguments go on stack which go in registers?
<fijal>
or should I ignore it and follow the aarch64 calling convention (8 regular args in registers and 8 floats)
<arigato>
it's not clear to me what the two choices are
<arigato>
in order to emit calls, then yes, you have to follow the existing calling convention
<fijal>
yes ok
<fijal>
but the current arm backend does something complicated I don't fully understand
<fijal>
is there a point, or is arm (32bit) using some complicated calling convention I don't care about
<arigato>
that's because the platform has a complicated convention
<arigato>
it's probably easier on aarch64
<fijal>
right, but aarch64 doesn't
<arigato>
because on arm32 they need to care about machines without a FPU, so they need to put floats and doubles in the regular registers too
<fijal>
so I should not try to read the current arm backend then?
<arigato>
and there is the issue about passing longlong arguments, which don't exist on 64-bit too
<arigato>
no, it's fine if you don't read that
<arigato>
the calling conventions are very often made far more complicated than necessary, for no reason
alawrence has quit [Ping timeout: 256 seconds]
lritter has joined #pypy
<kenaan>
rlamy optimizeopt-cleanup bfb1648a41f4 /rpython/jit/metainterp/pyjitpl.py: inline compile_loop_or_abort() and simplify
<antocuni>
arigato, fijal: do you have a clue about the bridge question I posted above? I am wondering whether this is the expected behavior (but unexpected to me) or if there is possibly a bug somewhere
nopf has joined #pypy
_whitelogger_ has joined #pypy
_whitelogger has quit [Ping timeout: 240 seconds]
<mattip>
fijal: could you redirect speed.pypy.org to CNAME lb.nyc1.psf.io and not what I previously said?
forgottenone has quit [Quit: Konversation terminated!]
oberstet has quit [Remote host closed the connection]
antocuni has joined #pypy
moei has joined #pypy
<mattip>
fijal: it works now, thanks! Next up - getting the hetzner machine to run and upload pypy benchmarks
antocuni has quit [Ping timeout: 255 seconds]
marky1991 has quit [Ping timeout: 246 seconds]
rtw_ has joined #pypy
marky1991 has joined #pypy
lritter has quit [Remote host closed the connection]
alawrence has joined #pypy
<alawrence>
I am trying to debug some code that is executed in a thread an am receiving ValueError: signal only works in main thread or with __pypy__.thread.enable_signals()
<alawrence>
how do I work around this or enable signals as it suggests?
<simpson>
Presumably the workaround is to not call `signal` stuff from anywhere but the main thread.
<alawrence>
simpson: Does that mean I cannot do - import pdb; pdb.set_trace() - inside a thread?
<simpson>
alawrence: Aha! Yeah, likely not without first doing something like the enable_signals() call recommended.