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> writes:
> Hello there,
> 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.