Hi Rocky, Sorry about the late reply.
On Sun, Mar 21, 2010 at 3:52 AM, Rocky Bernstein <rocky.bernst...@gmail.com> wrote: > Comments in line. > > On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko <li...@onerussian.com> > wrote: >> >> On Sat, 20 Mar 2010, Rohan Nicholls wrote: >> > > Ipython + python-mode + python-ropemacs + pylint + flymake + outline >> > > >...< >> > I have also used such a setup, and it has a lot to offer, but I found >> > that it really dies on you when you work with big projects. I think >> > >...< >> I had similar slowdown/cpu_intensive experience with some versions of >> pylint and more or less large projects but then it somehow became sane >> again (didn't check if any recent version changelog had any >> performance/dependecy_tracking improvements mentioned) >> >> > emacs frontend to rpdb (command line version of the winpdb debugger), >> > which seems to handle threading as well if not better than anyone >> > else. Pdb falls down horribly when dealing with multi-threaded >> > applications such as a wx-python or zope app. >> what about pydb (or even may be a new rewrite pydbgr ?) >> >> I bet Rocky >> (their author) who is also an emacs user might like to join the forces >> to provide adequate glue? > > Of course, I'm happy to work with folks who are interested in using pydbgr > and ensuring it plays nice with other tools. Strategically I'd like to see > it and other debuggers of this ilk use DBGp, the remote debugging protocol. > See http://xdebug.org/docs-dbgp.php. > > Right now though pydbgr has remote debugging support using a home-grown > protocol based on the Ruby debugger ruby-debug. And by the way, both pydb > and pydbgr do support working with threads. > > As for emacs and debugger integration, see the emacs-dbgr project on github > http://github.com/rocky/emacs-dbgr. It has lots of rough edges but > personally I use it all the time. Generally though I use it with debuggers > such as for Ruby, POSIX shells and gdb since I don't do much Python coding. I have been looking at this, but the docs seem a little scarce and I have not yet had time to start looking through the code. but man, you have a lot of tests. Nice work. > emacs-dbgr definitely is a much better foundation to work with on the Emacs > side for debuggers than gud.el. It makes better use of Emacs Lisp and Emacs > built in capabilities. For example it uses marks to store locations in the > source and process buffers; it uses a ring to store history locations and > buffer-local structs to store debugger information. > > Right now emacs-dbgr only supports for pydbgr with regards to Python, but > adding other debuggers such as pdb, pydb, or rpdb is pretty easy. If someone > is interested in that let me know. Well I would be, as zope2 which is what plone runs on only supports python 2.4 which rules out pydbgr (as much as I would like to use it), so I am reading the docs for pydb at the moment, and am happy to start hacking it into the emacs-dbgr project. Really nice idea by the way, and very needed, there are so many debuggers that run through emacs, and gud is indeed very static compiler oriented. > The gating factor on all of this development work is that the lack of > interest in the community. Personally I don't have need to use Python right > now, and historically ipython and Python folks haven't been much interested > in pydb let alone pydbgr. But to be fair, I'm not sure that historically > there has been all that much interest in pdb either. This is an unfortunate problem. The winpdb developer has brought this up on his blogs. :) Btw. is there a mailing list or something for emacs-dbgr? Thanks for all this work, it is really great, although I am curious as to why, if you don't use python much yourself, you are writing an improved debugger for it. Rohan _______________________________________________ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode