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

Reply via email to