From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ken manheimer Newsgroups: gmane.emacs.devel Subject: Re: Current state of python.el in the Emacs trunk Date: Tue, 29 Mar 2011 00:58:39 -0400 Message-ID: References: <4D40F55C.2040400@gmail.com> <874o85t61z.fsf@liv.ac.uk> <87y65hukcj.fsf@stupidchicken.com> <86r5b8llwc.fsf@gmail.com> <87oc66ky5s.fsf@liv.ac.uk> <861v2y9cz1.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636426743bf0747049f97ead7 X-Trace: dough.gmane.org 1301374765 10262 80.91.229.12 (29 Mar 2011 04:59:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2011 04:59:25 +0000 (UTC) Cc: Chong Yidong , Dave Love , Stefan Monnier , "emacs-devel@gnu.org" To: Christoph Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 29 06:59:19 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4R1Q-0008SC-Qy for ged-emacs-devel@m.gmane.org; Tue, 29 Mar 2011 06:59:19 +0200 Original-Received: from localhost ([127.0.0.1]:59684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4R1P-0001Kw-J0 for ged-emacs-devel@m.gmane.org; Tue, 29 Mar 2011 00:59:15 -0400 Original-Received: from [140.186.70.92] (port=36244 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4R1A-0001Kl-DP for emacs-devel@gnu.org; Tue, 29 Mar 2011 00:59:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4R18-0000NP-KP for emacs-devel@gnu.org; Tue, 29 Mar 2011 00:59:00 -0400 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:35366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4R15-0000Mv-TE; Tue, 29 Mar 2011 00:58:56 -0400 Original-Received: by wwb39 with SMTP id 39so3394392wwb.30 for ; Mon, 28 Mar 2011 21:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WlzLQkKU7wAfh9RpCmXI8emvJmhpgu1d7aQSfyYusDk=; b=cVKsEsc79KHwSakzv6o8ehqF3wD0TY1umEYM3+1s8peEoWp3P7feodYy50Z0TQKn7E dwpi664+nC2H/gwYYxyPzWNvuAVpFvJ4iLm7pK80b2jPS00MsRwSeETU1ehTLVPOuH0h SXu9ONqQMIueGAfAH28XimliwOLkS7Awp75BI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VX7iAUKMU6lv7XI8S3B/hhBpbstvremu4mj1lYuuoLwq2hjBEg1rPJ76f7gNWfhO9/ /CTMFVilXbltfAyaRV0j1WnKLS+Zhs4kKaUFyna0+2dfc3VGVgmZa+KX2QjiWP3qlvM6 X7Bv17PI69MmLtsYMXCYlcN0tyvnsE7f8T4Zc= Original-Received: by 10.216.183.148 with SMTP id q20mr4386168wem.88.1301374734108; Mon, 28 Mar 2011 21:58:54 -0700 (PDT) Original-Received: by 10.216.70.203 with HTTP; Mon, 28 Mar 2011 21:58:39 -0700 (PDT) In-Reply-To: <861v2y9cz1.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.49 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137834 Archived-At: --001636426743bf0747049f97ead7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 24, 2011 at 1:13 AM, Christoph wrote: > Dave Love writes: > > > I'm not sure what fixes you mean. I've just maintained a separate > > version. > > I was volunteering in case you were willing to let us incorporate any > fixes and improvements you made to your separate mode into the trunk but > couldnt or didnt want to do it yourself. The commentary of your file > says that certain bugs have been fixed, iirc. > > > That stuff simply shouldn't be there, which is why it originally > > wasn't. > > That's what I am currently working on cleaning up. This is mainly to > provide a cleaner base for the integration of functionality from > Fabian's new mode. > > > It appears all the world's Python, so it doesn't matter if it causes > > global problems and more-or-less excludes similar things for other > > interpreters as far as I remember. (I implemented a gud-minor-mode, of > > course, but it required changes to gud.el and I didn't keep up with > > Emacs. I think the general facility was less code than the > > Python-specific version.) > > I am unclear as to how gud-minor-mode would be better, since I am not > familiar with that mode at all. However, I remember reading in some old > thread where somebody made the point that Python's way of debugging > doesn't lend itself well to using a gud-minor-mode. I might have to go > back and reread that thread again. > > Christoph sorry it's about a month later, but i wasn't aware of these conversations until this eve. i expect that the point to which you're referring is mine, stated in the message included below. the upshot is that, in my not-so-recent acquaintance with gud and gdb-oriented debugging, they're oriented to be used as executives, running the program being debugged. this (if it is, in fact, the case) is extremely cumbersome and limited when it comes to debugging very dynamic languages, where you may want to embark on debugging in the middle of an already-executing run, dropping to an interactive session when a traceback is encountered. this is useful for many programs, and crucial for long running servers (like zope, which was my main focus when i developed pdbtrack for python-mode.el). when i originally developed pdbtrack i looked at gud integration, and it was horrifying. i got 90% of what i needed by using a comint output filter which noticed the python debugger's (pdb's) characteristic output and fetched the corresponding files in another buffer, with the overlay-arrow on the current line, and tracking execution as you interact with the python debugger in whatever the shell is where it's running. i did that with less that 150 lines of elisp lines, including a lot of comments. i depend on it daily when debugging python within emacs, and i think many other emacs / python users do, too. i was spurred to speak up when dave suggested in the thread (as i excerpted in the following message) that "it's not difficult to restructure GUD" to provide the functionality, and therefore "and it's not clean to make an add-on, which is why it's [pdbtrack, i believe] not in python.el". it sounded like, by suggesting providing the functionality with gud, dave was missing and/or dismissing some central features which make pdbtrack useful. i can see making it easy to disable for the people who don't want to use it, but making it unavailable for those who need it was a very frustrating prospect. however, pdbtrack does seem to be present in the versions of python.el that come with emacs 23 on the various systems i use, so i'm hopeful it's been adopted and will continue to be. ken ---------- Forwarded message ---------- From: ken manheimer Date: Thu, Feb 19, 2009 at 3:21 PM Subject: Re: replacing python.el To: Dave Love Cc: Glenn Morris , "skip@pobox.com" , " rms@gnu.org" , "python-mode@python.org" , "XEmacs-Beta@xemacs.org" , "barry@python.org" < barry@python.org>, "fbe2@comcast.net" , " emacs-devel@gnu.org" sorry to be late to this python.el / python-mode.el convergence discussion. i'm concerned that what dave is describing would not preserve a crucial feature of pdbtrack, a feature that may be a reason some python developers choose python-mode.el over python.el. (it is for me.) On Sun, Feb 1, 2009 at 3:51 PM, Dave Love wrote: >[...] > Indeed, and I don't understand what other problem there is with it, > other than maintenance. Why does it need to be replaced with > python-mode.el, even if that was properly assigned? > > The only other worthwhile feature I know of sort-of from python-mode.el > is related to something called pdbtrack (?). My commentary explains > that part of the functionality already exists, and something more > general than the rest should be a general feature in GUD. (The > Python-specifics are already there.) It's not difficult to restructure > GUD -- or wasn't when I hacked it originally -- and it's not clean to > make an add-on, which is why it's not in python.el. I know there isn't > interest in abstractions like that, but I didn't want to preempt a > possible change of opinion. when i last looked at it, gud was a terrible fit for pdbtrack. if things haven't changed drastically, i'm concerned that what you're suggesting would sacrifice pdbtrack's dynamicism. this is all the more worrisome since i spent some time porting pdbtrack to python.el. it's currently there in emacs 23.0.90, but i see it's not in the emacs that comes w/recent ubuntu, emacs 22.2. here's the scoop, as best i can describe it. gud is oriented to being in control of debugging, in particular launching the program being debugged, or injecting a connection to the executive to start the debugging at an arbitrary point, or post-mortem. pdbtrack, on the other hand, simply works wherevever python's debugger, pdb, does. the pdbtrack code is responsible for detecting pdb activity within an (any) emacs shell and presenting, in a companion buffer, the source file and line that pdb is reporting as the current instruction. pdbtrack provides functionality for python's debugger, pdb, much like edebug does for emacs lisp, except that pdb can be triggered as a statement within the subject program's code, and not just taking over execution of the program (as gdb and edebug do), or run onerror/post-mortem. (pdb also provides those modes.) this turns out to be invaluable in general, and especially for long-running programs like servers, where you want debugging to trigger in very specific situations. with pdb, you just situate the debug-triggering code exactly in the situation (i wish i could do this with edebug), or as error handling around the situation. gud may have facilities that could be used to enhance pdbtrack, but i don't think it is designed to operate the way i describe above. plus, gud is massive, and i suspect it would take more emacs lisp code to craft gud python accommodations than all of pdbtrack (last i checked around 150 lines, including copious comments). i hope this is clear. as i said, pdbtrack porting to python.el has already been done, it just isn't in the currently released version. and, of course, there are other benefits to be had from a python-mode.el/python.el convergence, but i want to make sure this one, at least, is preserved. (i also think the pdbtrack approach would be appreciated for other dynamic languages, including emacs lisp.) -- ken http://myriadicity.net > --001636426743bf0747049f97ead7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 24, 2011 at 1:13 AM, Christoph <cschol2112@go= oglemail.com> wrote:
Dave Love <fx@gnu.org> writes:

> I'm not sure what fixes you mean. =A0I'= ;ve just maintained a separate
> version.

I was volunteering in case you were willing to let us incorporate any=
fixes and improvements you made to your separate mode into the trunk but couldnt or didnt want to do it yourself. The commentary of your file
says that certain bugs have been fixed, iirc.

> That stuff simply shouldn't be there, which is why it originally > wasn't.

That's what I am currently working on cleaning up. This is mainly= to
provide a cleaner base for the integration of functionality from
Fabian's new mode.

> It appears all the world's Python, so it doesn't matter if it = causes
> global problems and more-or-less excludes similar things for other
> interpreters as far as I remember. =A0(I implemented a gud-minor-mode,= of
> course, but it required changes to gud.el and I didn't keep up wit= h
> Emacs. =A0I think the general facility was less code than the
> Python-specific version.)

I am unclear as to how gud-minor-mode would be better, since I am not=
familiar with that mode at all. However, I remember reading in some old
thread where somebody made the point that Python's way of debugging
doesn't lend itself well to using a gud-minor-mode. I might have to go<= br> back and reread that thread again.

Christoph

sorry it's about a mon= th later, but i wasn't aware of these conversations until this eve. =A0= i expect that the point to which you're referring is mine, stated in th= e message included below. =A0the upshot is that, in my not-so-recent acquai= ntance with gud and gdb-oriented debugging, they're oriented to be used= as executives, running the program being debugged. =A0this (if it is, in f= act, the case) is extremely cumbersome and limited when it comes to debuggi= ng very dynamic languages, where you may want to embark on debugging in the= middle of an already-executing run, dropping to an interactive session whe= n a traceback is encountered. =A0this is useful for many programs, and cruc= ial for long running servers (like zope, which was my main focus when i dev= eloped pdbtrack for python-mode.el).

when i originally developed pdbtrack i looked at gud in= tegration, and it was horrifying. =A0i got 90% of what i needed by using a = comint output filter which noticed the python debugger's (pdb's) ch= aracteristic output and fetched the corresponding files in another buffer, = with the overlay-arrow on the current line, and tracking execution as you i= nteract with the python debugger in whatever the shell is where it's ru= nning. =A0i did that with less that 150 lines of elisp lines, including a l= ot of comments. =A0i depend on it daily when debugging python within emacs,= and i think many other emacs / python users do, too.

i was spurred to speak up when dave = suggested in the thread (as i excerpted in the following message) that &quo= t;it's not difficult to restructure GUD" to provide the functional= ity, and therefore "and it's not clean to= =A0make an add-on, which is why it's [pdbtrack, i believe] not in pytho= n.el". =A0it sounded like, by suggesting providing the functionality w= ith gud, dave was missing and/or dismissing some central features which mak= e pdbtrack useful. =A0i can see making it easy to disable for the people wh= o don't want to use it, but making it unavailable for those who need it= was a very frustrating prospect. =A0however, pdbtrack does seem to be pres= ent in the versions of python.el that come with emacs 23 on the various sys= tems i use, so i'm hopeful it's been adopted and will continue to b= e.

ken

---------- Fo= rwarded message ----------
From:=A0ken manheimer=A0<ken.manheimer@gmail.com= >
Date: Thu, Feb 19, 2009 at 3:21 PM
Subject: Re: replacing= python.el
To: Dave Love <fx@gnu.org>
Cc: G= lenn Morris <rgm@gnu.org>, "<= a href=3D"mailto:skip@pobox.com">skip@pobox.com" <skip@pobox.com>, "rms@gnu.org" <rms@gnu.org= >, "python-mode@pytho= n.org" <python-mode@p= ython.org>, "XEmacs-B= eta@xemacs.org" <XEma= cs-Beta@xemacs.org>, "barry= @python.org" <barry@python.= org>, "fbe2@comcast.net= " <fbe2@comcast.net>, &q= uot;emacs-devel@gnu.org" &l= t;emacs-devel@gnu.org>


sorry to be late to this python.el / python-mode.e= l convergence
discussion. =A0i'm concerned that what dave is describ= ing would not
preserve a crucial feature of=A0pdbtrac= k, a feature that may be a reason
some python developers choose python-mode.el over python.el. =A0(it is
f= or me.)

On Sun, Feb 1, 2009 at 3:51 PM, Dave Love <fx@gnu.org> wrote:
>[...]
> Indeed, and I don't understand what other problem there is with it= ,
> other than maintenance. =A0Why does it need to be replaced with
>= ; python-mode.el, even if that was properly assigned?
>
> The o= nly other worthwhile feature I know of sort-of from python-mode.el
> = is related to something called=A0pdbtrack=A0(?). = =A0My commentary explains
> that part of the functionality already exists, and something more
&= gt; general than the rest should be a general feature in=A0GUD. =A0(The
> Python-specifics are already there.) =A0It&#= 39;s not difficult to restructure
>=A0GUD=A0-- or wasn't when I hacked it or= iginally -- and it's not clean to
> make an add-on, which is why = it's not in python.el. =A0I know there isn't
> interest in ab= stractions like that, but I didn't want to preempt a
> possible change of opinion.

when i last looked at it,=A0<= span class=3D"il">gud=A0was a terrible fit for=A0= pdbtrack. =A0if
things haven't changed drastically, =A0i'= m concerned that what you're
suggesting would sacrifice=A0pdbtrack's dynam= icism.

this is all the more worrisome since i spent some time portin= g
pdbtrack=A0to python.el. =A0it's current= ly there in emacs 23.0.90, but i
see it's not in the emacs that comes w/recent ubuntu, emacs 22.2.
here's the scoop, as best i can describe it.

gud=A0is oriented to being in control of debugging, in particular<= br> launching the program being debugged, or injecting a connection to
the e= xecutive to start the debugging at an arbitrary point, or
post-mortem.
pdbtrack, on the other hand, simply works w= herevever python's
debugger, pdb, does. =A0the=A0pdbtrack=A0code is = responsible for detecting
pdb activity within an (any) emacs shell and p= resenting, in a
companion buffer, =A0the source file and line that pdb i= s reporting as
the current instruction.

pdbtrack=A0provid= es functionality for python's debugger, pdb, much like
edebug does f= or emacs lisp, except that pdb can be triggered as a
statement within th= e subject program's code, and not just taking over
execution of the program (as gdb and edebug do), or run
onerror/post-mor= tem. =A0(pdb also provides those modes.) =A0this turns out
to be invalua= ble in general, and especially for long-running programs
like servers, w= here you want debugging to trigger in very specific
situations. =A0with pdb, you just situate the debug-triggering code
exac= tly in the situation (i wish i could do this with edebug), or as
error h= andling around the situation.

gud=A0may ha= ve facilities that could be used to enhance=A0pdbtrack, but i
don't think it is designed to operate the way i describe above. =A0plus= ,
gud=A0is massive, and i suspect it would tak= e more emacs lisp code to
craft=A0gud=A0python= accommodations than all of=A0pdbtrack=A0(last i = checked
around 150 lines, including copious comments).

i hope this is clear.= =A0as i said,=A0pdbtrack=A0porting to python.el = has
already been done, it just isn't in the currently released versi= on.
and, of course, there are other benefits to be had from a
python-mode.el= /python.el convergence, but i want to make sure this
one, at least, is p= reserved. =A0(i also think the=A0pdbtrack=A0appro= ach
would be appreciated for other dynamic languages, including emacs
lisp.)=
--
ken
http://myriadicity.net
= =A0
=A0

--001636426743bf0747049f97ead7--