Thank you for the quick response!
So, in reality, using the remote debugger only helps my poor NCurse-ing
skills and freezing execution "in the middle" of drawing.
Otherwise, I have to plan ahead in order to debug my contraption.
(Or, now that I think of it, I can have a 'def *: pass' that I can execute
on a whim that carries an unconditional breakpoint).
_In Jira/Ticket logic, you can close the ticket, as I feel satisfied given
On 26 January 2018 at 17:58, Andreas Kloeckner <lists(a)informa.tiker.net>
Ntentos Stavros <stdedos+pudb(a)gmail.com>
I am trying to debug a NCurses application - so I am using remote
as a way to use a different terminal for the
application and the
However, why does debugger disappear on
execution? Wouldn't it be okay to
be open and working, and allow to set breakpoints even when not stopped?
There are two separate problems in what you're describing.
- First, why does the debugger disappear? That's because that's what has
to happen when the debuggee and the debugger share a terminal. That
could conceivably be avoided in the remote case.
- Second, why does the debugger stop? bdb/pdb/pudb are designed to share
control flow with the main program, so when the main program runs,
they don't. That one would entail redesigning pudb to be split into a
client/server model, like winpdb. If the two parts are connected by
(say) a socket rather than by sharing execution flow, it's easy to
have the debugger continue while the debuggee executes.