Hi Rocky,
I am replying up the email chain, just to put a snippet that might be helpful.
I have been using the pdb function in emacs, to do some debugging, and
I have not
yet got emacs-dbgr and pydb working together (more lack of time and effort than
that it is particularly difficult), and due to time constraints I have
been using the
pdb command. This is working with the tracking functionality fine,
but pdb is very
limited and is completely missing things in other threads. So as a
quick hack, I
poked around and got friendly with regexp-builder.
This should allow pdb to track using pydb:
(setq gud-pdb-marker-regexp "^[>(
]*\\([-a-zA-Z0-9_/.\\]*\\|<string>\\)[:(]\\([0-9]+\\)):*\s\\{0,2\\}\\(<module>\\|[azA-Z0-9_]*\\|\\?\\)[()]*\\(->[^\n]*\\)?\n")
At least it works for me.
I will post more as I get the emacs-dbgr and pydb working together. :)
Thanks for the tool, pydb has so much cool stuff, it will take some
playing and reading to figure it all out.
Rohan
On Thu, May 20, 2010 at 4:51 PM, Rohan Nicholls
<rohan.nicho...@googlemail.com> wrote:
> 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
