<cr1901_modern>
"Exceptions are cleared because with the traceback attached to them, they form a reference cycle with the stack frame" <= No doubt b/c I know little about Pythons internals, but I wonder why that's the case
<whitequark>
short answer: python internals are gross and python doesn't strive to get either a clean spec or a clean impl all that much
<whitequark>
I am not sure if it /has/ a single coherent spec, much less formal semantics
<whitequark>
(no, docs plus a bunch of PEPs don't count)
<sb0>
so if you store the exception after catching it in a except clause, do bad things happen?
<cr1901_modern>
Interesting you should mention the parentheses, b/c I can't recall seeing anything about semantics either aside from tidbits like the above in the docs
<whitequark>
sb0: what I gather is that you need a full mark/sweep cycle to collect it
<whitequark>
as opposed to just refcounting doing that
<whitequark>
i.e. it is a crude performance hack that only ever matters for cpython that leaked into language semantics
<whitequark>
see above.
<cr1901_modern>
If Python was refcounting, wouldn't the end of the exception just decrease the refcount, and the variable would live until you got to the end of f()?
<whitequark>
exceptions keep a reference to the frame
<whitequark>
i.e. function stack frame
<cr1901_modern>
Ahhh, I see (I think). the exception would have access to everything then, so in your case, it assigns "x" to the exception object, then deletes it at the end of the exception. >>
<cr1901_modern>
Which thereby destroys the variable you had before the exception?
<whitequark>
except clause, yes
<whitequark>
yes
<cr1901_modern>
Yea, that seems like a mess/shouldn't be by design o.0;
<whitequark>
I'm not even sure why would you raise so many times that it will matter
<whitequark>
my crystal ball says that this is a remnant from the time when python didn't have a tracing GC
<whitequark>
though it is still beyond me why it's in 3k
<cr1901_modern>
I'm not even sure what optimizations this behavior allows, tbh.
<whitequark>
one tracing GC cycle less
<cr1901_modern>
I'll make a memo of that and look up what a tracing GC does later. But what about pre-tracing GC (as your crystal ball predicts it's a remnant from the dark ages)?
<whitequark>
avoids a leak
fengling has joined #m-labs
<GitHub58>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vk8pX
<key2>
i mean, if i use an external verilog source, i can still simulate properly, right ?
<key2>
as it's passed to icarus through the VPI at simulation time
* ysionneau
never tried that
<ysionneau>
key2: I just tried a simple example, it seems to work fine, you just need to add your extra verilog files when instanciating the icarus.Runner : icarus.Runner(extra_files=["your_verilog.v"])
<ysionneau>
and now I remember I already did that obviously, when simulating the memory controller (in migen) connected to a Micron DRAM model (in plain verilog)
antgreen` has quit [Ping timeout: 250 seconds]
hozer has joined #m-labs
sb0_ has quit [Quit: Leaving]
sh[4]rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
<sb0>
ubuntu is such a piece of crap. trying to upgrade: 1) fontconfig breaks and apt-get stops configuring packages and refuses to install anything after that until i had to use dpkg manually to upgrade the package that broke fontconfig 2) upgrading gnome deinstalled systemd
<sb0>
after fixing those, gdm doesn't start anymore for some reason
key2 has quit [Ping timeout: 246 seconds]
<GitHub27>
[artiq] fallen pushed 1 new commit to master: http://git.io/vkRdS
<GitHub27>
artiq/master 7ec0bc0 Yann Sionneau: manual: explain how to compile and flash the idle kernel
<GitHub175>
[artiq] fallen pushed 2 new commits to master: http://git.io/vkRNQ
<GitHub175>
artiq/master d5fb50b Yann Sionneau: manual: after artiq is installed, frontends can be used without path prefix...