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
speeder39_ has joined #pypy
CrazyPython has quit [Remote host closed the connection]
CrazyPython has joined #pypy
BPL has quit [Quit: Leaving]
CrazyPython has quit [Remote host closed the connection]
CrazyPython has joined #pypy
CrazyPyt_ has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
jcea has quit [Remote host closed the connection]
CrazyPyt_ has quit [Remote host closed the connection]
CrazyPython has quit [Read error: Connection reset by peer]
mattip has joined #pypy
oberstet has quit [Remote host closed the connection]
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
andi- has quit [Remote host closed the connection]
andi- has joined #pypy
<arigato>
cfbolz: now yes
<arigato>
tos9: cool. thanks for the effort. In theory we could convert the whole repo of pypy to a correct git-with-notes and then use your GH action to ensure any newly pushed commits get a note too, right?
<arigato>
mjacob: there are no regular releases of revdb. Maybe there should be
<cfbolz>
arigato: I think there is a fundamental problem with fset_f_lineno, but I can't figure it out
<arigato>
ugh
<cfbolz>
yes :-(
<arigato>
well that code has always been a hack, I'm not surprised if it gets out of sync with what the compiler produces (both in CPython and in PyPy)
<cfbolz>
no, it's really a fundamental flaw, if I see that correctly
<cfbolz>
arigato: our code tries a single pass across the bytecodes to understand the block handling
<cfbolz>
but sometimes there are two different ways we can reach a finally:
<cfbolz>
this example really never worked, as far as I can tell, jumping from 6 to 7
<arigato>
did you try these examples on a range of CPython versions?
<cfbolz>
no, just 3.6
<arigato>
what is the pdb command to change the current line..?
<cfbolz>
arigato: look at py3.6-fix-set-lineno
<cfbolz>
(but probably ignore the logic in 577840a9fd64, I am not sure it's correct)
<cfbolz>
anyway, the examples pass in 2.7
<arigato>
ah, "jump"
<cfbolz>
yes, it's a bit of a mess. it's an adapted version of test_sys_settrace.py
<arigato>
in my pypy3, if I paste jump_over_return_in_try_finally_block() in x.py and add pdb.set_trace() after the "output.append(3)" then I can jump to the line "output.append(6)"
<cfbolz>
arigato: ok, but the second example doesn't work, right?
<arigato>
no
<arigato>
SystemError: END_FINALLY not properly nested in this bytecode
<cfbolz>
arigato: right
<arigato>
maybe we could use a different approach
<arigato>
I think the only concern is that the block stack and the value stack should be "the same" where we jump to, right? for some definition of "sameness"
<cfbolz>
yes, that's what CPython does
<cfbolz>
arigato: but the comments look like they have bugs that we fix
<cfbolz>
(maybe that's better in CPy 3.6 though)
<arigato>
right
<arigato>
(maybe something like "jumping from b1 to b2 is fine if there is a path, going backward and/or forward one bytecode at a time, which never pops more of the two stacks than what they currently have")
<cfbolz>
arigato: anyway, you don't really have much memory writing this code, do you? Because I can certainly try to follow CPython's logic and see what breaks
<arigato>
I think it's a good idea, if the logic in CPython changed
<arigato>
I have some memories but also I know that it's fragile and was never designed for something else than 2.7
<arigato>
(at that point in time, by copying CPython's behavior and finding bugs in it)
<cfbolz>
arigato: right
<cfbolz>
Ok, will try (in any case, even our 2 version has the bug you just saw, I think)
<arigato>
I didn't get any bug in pypy2, with the approach I described
<cfbolz>
Ah, interesting
<cfbolz>
Then it's maybe indeed because some details of the bytecodes changed
<cfbolz>
The differences between the blockstack handling gives me headaches
<arigato>
my guess is that CPython realized the algo they used wouldn't work, and changed it
<cfbolz>
Right
<arigato>
what gives me headaches is the difference between blockstack handling of the *same* bytecode depending on the phase of the moon, in CPython
<cfbolz>
Exactly
<arigato>
(no clue how they managed to get such a messy set of bytecodes *and* still have syntax that produces tons and tons of bytecodes instead of just a few </rant>)