Re: plan for emacs python tooling (esp python.el, python-mode.el)?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: plan for emacs python tooling (esp python.el, python-mode.el)?

Andreas Röhler-2
Stefan Monnier wrote:

>> summary: Is the near-term plan for GNU emacs (e.g. for 2010-2011) to
>> ship with python.el, python-mode.el, both, or something completely
>> different?
>
> The plan is to ship it with python.el until we can ship it with
> python-mode.el (the barrier being coipyright assignments).
>
>
>         Stefan
>
>
>

Hi Stefan,

as far as I understand the OP, the focus is rather the python-environment than the editor.

As far as it concerns editing, python.el, python-mode.el are both suitable IMHO.

Don't see a real gain by switching one for the other. If a precise feature is missed here or there, let's implement it...

Progress would mean having a download source for an environment, which offers all needed at once:
debugging, refactoring, auto-completion etc.

Such an environment should enable emacs editing modes, but vim and other free tools too.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: plan for emacs python tooling (esp python.el, python-mode.el)?

Eric M. Ludlam
On 03/16/2010 06:47 AM, Andreas Roehler wrote:

> as far as I understand the OP, the focus is rather the python-environment than the editor.
>
> As far as it concerns editing, python.el, python-mode.el are both suitable IMHO.
>
> Don't see a real gain by switching one for the other. If a precise feature is missed here or there, let's implement it...
>
> Progress would mean having a download source for an environment, which offers all needed at once:
> debugging, refactoring, auto-completion etc.
>
> Such an environment should enable emacs editing modes, but vim and other free tools too.
The CEDET support for python parsing (which would handle autocompletion
type tasks amonng others) is also (as far as I know) held up by a
copyright assignment.

Exuberent ctags supports python (though I don't know by how much), and
adding support in the CEDET/Semantic exuberant ctags support wouldn't be
too hard.  Likely something like the patch attached.

Hmmm.  I see that the exuberent ctags support does not appear to be a
part of Emacs.  Well, you could try the most recently posted version of
CEDET with the below patch instead if you wanted to try it.

Eric

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

semantic-ectag-lang.el.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: plan for emacs python tooling (esp python.el, python-mode.el)?

Tom Roche

summary: I'll followup with the python*el folks and CEDET regarding
current and future python development environments for GNU emacs.

details:

Tom Roche Mon, Mar 15, 2010 at 11:47 AM
>>>> Is the near-term plan for GNU emacs (e.g. for 2010-2011) to ship
>>>> with python.el, python-mode.el, both, or something completely
>>>> different?

Stefan Monnier Mon, 15 Mar 2010 23:58:04 -0400
>>> The plan is to ship it with python.el until we can ship it with
>>> python-mode.el (the barrier being [copyright] assignments).

<sigh/> Given the duration of that barrier to date, ISTM one must
assume python-mode.el's copyrights won't be assigned.

Andreas Roehler Tue, 16 Mar 2010 11:47:57 +0100 (rearranged)
>> as far as I understand the OP, the focus is rather the python-
>> environment than the editor.

That is technically correct, but (I suspect, and ICBW) practically,

* the python development environment needs a platform.

* Given that coding python ~= editing test files, that platform is
  most reasonably a text editor.

Hence I want a

>>>> PDEE à la the JDEE

http://jdee.sourceforge.net/
>>>>> A Java Development Environment for Emacs
...
>>>>> JDEE features include
...
>>>>> * syntax coloring
>>>>> * auto indentation
>>>>> * compile error to source links
>>>>> * source-level debugging
>>>>> * source code browsing
>>>>> * make file support
>>>>> * automatic code generation

IIUC this is the "best of breed" code environment for GNU emacs (am I
missing something?) so I regard it as a model.

>> Such an environment should enable emacs editing modes, but vim and
>> other free tools too.

Again, technically correct, but

* I want a python development environment for GNU emacs, since that's
  what my fingers know. (Which is why I'm not (at least initially)
  getting Wing or PyDev: I'd end up using emacs to edit the files
  underneath, as I was forced to do when working on Eclipse.)

* The *macs ecosystem already contains robust tools for providing
  coder services (e.g. the "JDEE features" above), e.g. CEDET. Since
  the JDEE definitely exploits CEDET, and GNU emacs is apparently in
  the process of integrating CEDET (no?), I tend to assume a PDEE
  should do this too.

* I don't see the editor-independent interfaces to the services above.
  Am I missing something? (I am very new to python.)

If the above is true, then it seems the fastpath to a richer PDEE is
CEDET integration. No? Except ...

Eric M. Ludlam Tue, 16 Mar 2010 07:37:13 -0400
> The CEDET support for python parsing (which would handle
> autocompletion type tasks [among] others) is also (as far as I know)
> held up by a copyright assignment.

<sigh/> I'll followup about that separately.

your assistance is appreciated, Tom Roche <[hidden email]>
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: plan for emacs python tooling (esp python.el, python-mode.el)?

Barry Warsaw
In reply to this post by Andreas Röhler-2
>> The plan is to ship it with python.el until we can ship it with
>> python-mode.el (the barrier being coipyright assignments).

Although I believe I've already done so, I've repeatedly said that I have no
problem assigning my changes in python-mode.el to the FSF (again).  I think we
can get Skip, Ken, and Tim to do the same, though I also think some or all of
them have already done so.  I really don't know what more I can do about the
copyright assignment "problem".

That having been said, python-mode.el is GPL and I nothing against y'all
stealing as much from python.el as makes sense.  If python-mode.el is never
distributed with Emacs, so be it.  But there really shouldn't be anything
stopping python-mode.el from having the best of both worlds.

-Barry

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PDEE] CEDET integration with python-mode.el?

Tom Roche
In reply to this post by Tom Roche

Have you tried to use CEDET with python.el? If so, how did it work?
Why I ask:

I'm a longtime (though not expert) emacs user (currently using

GNU Emacs 23.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.0)
 of 2009-09-27 on crested, modified by Debian

aka ubuntu karmic package=emacs-snapshot), new python coder, and
former cperl and JDEE

http://jdee.sourceforge.net/

user. I'd like to have a python development environment for emacs
(PDEE) as useful as JDEE. Given my version of emacs, I got, and am
trying out, python.el, but I'm also trying out python-mode.el. It's
working well enough, but I'd really appreciate features like smart
completion. I'll try setting up pycomplete, but note

pycomplete.py
> (untried w/ GNU Emacs so far)
...
> This is unlikely to be done the way Emacs completion ought to be done,

It Seems To Me (quite possibly naively) that the best/easiest way to
get smarter completion particularly, and several more services
besides, is to use CEDET

http://cedet.sourceforge.net/

(as does JDEE). So I'm wondering if you (collectively) or someone you
know has tried that, how it worked, and (if it worked) what init.el
config code was required.

TIA, Tom Roche <[hidden email]>
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: plan for emacs python tooling (esp python.el, python-mode.el)?

Barry Warsaw
In reply to this post by Eric M. Ludlam
On Mar 16, 2010, at 07:37 AM, Eric M. Ludlam wrote:

>Exuberent ctags supports python (though I don't know by how much), and
>adding support in the CEDET/Semantic exuberant ctags support wouldn't be
>too hard.  Likely something like the patch attached.

exuberent-tags is a separate package on Ubuntu, and it supports Python well.
Actually too well IMO.  I don't like variable or import tags so something like
--python-kinds=-vi [*] should work pretty well.

-Barry

[*] ironic, ain't it? :)

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Yaroslav Halchenko-5
In reply to this post by Tom Roche

On Tue, 16 Mar 2010, Tom Roche wrote:

> It Seems To Me (quite possibly naively) that the best/easiest way to
> get smarter completion particularly, and several more services
> besides, is to use CEDET
or may be (citing my post earlier in this list):

Ipython + python-mode + python-ropemacs + pylint + flymake + outline
make emacs very well featured for Python mode development
(completions, documentation lookup, jump to definition, etc). You might
look into my messy .emacs setup [1] or excerpt from it, which I placed
into pymvpa project [2], on how to make such combination work nicely.

There is an ongoing discussion in python-mode mailing list [3]
regarding possible merge of python.el (shipped with GNU emacs) and
python-mode.el (separate project which originated at python.org)

[1] http://git.onerussian.com/?p=etc/emacs.git;a=summary
[2] http://git.debian.org/?p=pkg-exppsy/pymvpa.git;a=blob;f=doc/misc/emacs;h=42876c90a36ce73c34fc20408bfea44657e8a07a;hb=46624cd2bbc2f864621b7bd48673b44dc22af3e5
[3] http://mail.python.org/pipermail/python-mode/2009-February/thread.html

--
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]


_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Rohan Nicholls-3
On Sat, Mar 20, 2010 at 3:22 AM, Yaroslav Halchenko
<[hidden email]> wrote:

>
> On Tue, 16 Mar 2010, Tom Roche wrote:
>
>> It Seems To Me (quite possibly naively) that the best/easiest way to
>> get smarter completion particularly, and several more services
>> besides, is to use CEDET
> or may be (citing my post earlier in this list):
>
> Ipython + python-mode + python-ropemacs + pylint + flymake + outline
> make emacs very well featured for Python mode development
> (completions, documentation lookup, jump to definition, etc). You might
> look into my messy .emacs setup [1] or excerpt from it, which I placed
> into pymvpa project [2], on how to make such combination work nicely.

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
it is the rope library, because working on a zope project or the large
code base I was working on at my last job, and getting a completion or
saving a file would make everything really, really slow, or worse,
send rope into a complete tailspin.

I would love to see python and cedet come together, as there is so
much functionality out of the box with cedet, while with rope etc. the
project browsing is seriously lacking, as was semantic code
completion.

As fabulous as ipython is, it only understands what it has processed,
and has problems (not its fault, this is something that lies deep in
the python interpretor itself) updating the object environment, so
updating functions, methods and classes with ipython does not
necessarily update the current objects, in fact more often than not
doesn't.

I would also like to add; there is no really good python development
tools, and if pdee came about combining the cedet functionality with
good debugging integration, it would be ahead of current python ides
(IMHO).  About the debugging, I was thinking that maybe creating an
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.

One thing that is really nice about rope, is that it does handle
refactoring really well, in fact it had a lot of features that wingide
could not match (I have used both), but maybe cedet has these
facilities.

Anyway, that was my thinking. Do I have the slightest clue where to
start to make this happen?  Nope.  But I am still working in python,
and at the moment with zope, so I need to find or help build a
solution, and if it uses emacs as its frontend so much the better.

Thanks,

Rohan
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Yaroslav Halchenko-5

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? (CCing him just in case... for the complete
thread see

http://mail.python.org/pipermail/python-mode/2010-March/000751.html
--
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]


_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Rocky Bernstein
Comments in line.

On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko <[hidden email]> 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.

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.

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.
 
(CCing him just in case... for the complete
thread see

http://mail.python.org/pipermail/python-mode/2010-March/000751.html
--
                                 .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                  Linux User    ^^-^^    [175555]




_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Andreas Röhler-2
Rocky Bernstein wrote:

> Comments in line.
>
> On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko
> <[hidden email] <mailto:[hidden email]>> 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.
>
> 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.
>
> 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.

Hi Rocky,

great to see you here.

Not being that experienced python-user either, played a little bit with pydb.el and like it, as
it doesn't require an entry into the python-source. Thanks a lot BTW.

Most simply way getting your stuff distributed alongside with python-mode seems making a branch and upload it.

Once your branch(es) show up, it will be cared for connection into python-mode.

If you think that's to much, there should be ways mirrowing your stuff from the place it resides.

Thanks again


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/





>  
>
>     (CCing him just in case... for the complete
>     thread see
>
>     http://mail.python.org/pipermail/python-mode/2010-March/000751.html
>     --
>                                      .-.
>     =------------------------------   /v\  ----------------------------=
>     Keep in touch                    // \\     (yoh@|www.)onerussian.com
>     <http://onerussian.com>
>     Yaroslav Halchenko              /(   )\               ICQ#: 60653192
>                       Linux User    ^^-^^    [175555]
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Python-mode mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-mode

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Rohan Nicholls-3
In reply to this post by Rocky Bernstein
Hi Rocky,

Sorry about the late reply.

On Sun, Mar 21, 2010 at 3:52 AM, Rocky Bernstein
<[hidden email]> wrote:

> Comments in line.
>
> On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko <[hidden email]>
> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: [PDEE] CEDET integration with python-mode.el?

Rohan Nicholls-3
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
<[hidden email]> wrote:

> Hi Rocky,
>
> Sorry about the late reply.
>
> On Sun, Mar 21, 2010 at 3:52 AM, Rocky Bernstein
> <[hidden email]> wrote:
>> Comments in line.
>>
>> On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko <[hidden email]>
>> 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
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode