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 the limitations_ On 26 January 2018 at 17:58, Andreas Kloeckner <[email protected]> wrote: > Ntentos Stavros <[email protected]> writes: > > > Hello there, > > > > I am trying to debug a NCurses application - so I am using remote > debugging > > as a way to use a different terminal for the application and the > debugger. > > 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. > > HTH, > Andreas > >
_______________________________________________ Pudb mailing list [email protected] https://lists.tiker.net/listinfo/pudb
