I just used your printing trick. That ls command doesn't work in Mac OS X, but Terminal.app has an option to display the tty name in the window title, so I just used that (and wrote to /dev/ttys012 in my case).
Debugging one pudb with another seems quite impossible short of renaming one to something else, including all imports. Otherwise, it's very difficult to get Python to import both, and the import statements in each will confuse it. It was suggested to me that this could be made easier with relative imports, but I didn't want to change that without knowing if they could be supported by the Python versions that PuDB supports (hence my other email). Relative imports require Python 2.5+. Aaron Meurer On Sat, Aug 6, 2011 at 4:01 PM, Aaron Meurer <[email protected]> wrote: > On Sat, Aug 6, 2011 at 7:47 AM, Andreas Kloeckner > <[email protected]> wrote: >> On Sat, 6 Aug 2011 04:23:26 -0600, Aaron Meurer <[email protected]> wrote: >>> So I'm coming along with the variable wrapping stuff, but I'm running >>> into some problems that I think are the result of my ignorance of how >>> urwid and the majority of the pudb code works. >>> >>> Anyway, instead of wrapping properly, it crashes. Do you have any >>> suggestions on how to use pudb to debug itself? Ideally, I would like >>> to run the local pudb (which has the broken code) from within the >>> system pudb (which doesn't). Just post-mortem is fine. >>> >>> Otherwise, debugging pudb itself is ironically very difficult. Print >>> statements don't even work >> >> I've never tried any such thing, but I've definitely felt your >> pain. What I've usually done is used prints to a different terminal. >> >> ls -lah /proc/$$/fd >> >> will tell you what pseudoterminal an xterm is attached to, and then you >> can open that in a global variable and use it for debug output. Pudb's >> ability to debug itself mostly hinges on bdb's ability to do the same, >> and I've found it mostly incapable of doing so. (but I haven't tried >> very hard) >> >> Good luck, and hope this helps, >> Andreas >> > > That's a good idea. So far I've been "printing" things to the > terminal by raising exceptions with the stuff I want in the error > message, but this kills the program and is hard to control. > > I was able to debug pudb with itself back when I was working on the > prefs dialog, by doing > > try: > pudb.set_trace() > # Kill pudb > except: > pudb.post_mortem(sys.exec_info()) > > and it worked just fine, but that only worked because the prefs dialog > only died when I explicitly opened it and did something that killed > it. In this case, the variables view is needed every time, so it > won't work. But there shouldn't otherwise be a problem, as I'm > debugging the ui, not the debugger itself. > > I'll ask around to see if it is possible to run pudb both systemwide > and locally (maybe hacking sys.path at just the right time or > something). Otherwise, I guess I will just need to learn basic pdb > and use IPython's %pdb. > > Aaron Meurer > _______________________________________________ Pudb mailing list [email protected] http://lists.tiker.net/listinfo/pudb
