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: python.el fixes for Emacs 22 Date: Wed, 20 Feb 2008 19:20:53 -0500 Message-ID: <2cd46e7f0802201620o6b6190dcmb53805bbb30aa3ec@mail.gmail.com> References: <18356.54892.186541.669277@kahikatea.snap.net.nz> <861w7euz7a.fsf@lola.quinscape.zz> <2cd46e7f0802150943x46e9bcb0i4c3b6075d48cc979@mail.gmail.com> <18363.29854.271108.937443@kahikatea.snap.net.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1203553270 27744 80.91.229.12 (21 Feb 2008 00:21:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Feb 2008 00:21:10 +0000 (UTC) Cc: skip montanaro , rms@gnu.org, cyd@stupidchicken.com, Barry Warsaw , emacs-devel@gnu.org, sdl.web@gmail.com To: "Nick Roberts" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 21 01:21:33 2008 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.50) id 1JRzBs-0007BM-1z for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2008 01:21:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRzBN-0001mE-0s for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 19:21:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRzBJ-0001kf-7m for emacs-devel@gnu.org; Wed, 20 Feb 2008 19:20:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRzBI-0001kF-NE for emacs-devel@gnu.org; Wed, 20 Feb 2008 19:20:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRzBI-0001k7-Gf for emacs-devel@gnu.org; Wed, 20 Feb 2008 19:20:56 -0500 Original-Received: from hs-out-0708.google.com ([64.233.178.247]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRzBH-0008PE-TT for emacs-devel@gnu.org; Wed, 20 Feb 2008 19:20:56 -0500 Original-Received: by hs-out-0708.google.com with SMTP id j58so2432575hsj.10 for ; Wed, 20 Feb 2008 16:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=vLVfh5sUd4gvONhVwKfuYjSOITLoR1/19NZqLN+n+4A=; b=QJgRd+2wpVGksigWiZHK5nt0EngHQOtP1XPDMDrNlvNJZQJ5tPlvkYy+GA/4/g5RXHFhfkCzWrY8Ka15otoYq0FbIf7jtyauamr4Mz5AM8eaV40lTMK9paUrZtF1ZFMQb13fOlW4b0R5U/S4zkucLLlVZ8euDvyxPAKRDEpzmEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jrD/4Vd3uReE/T817XshfJZ56B3y4di6pZiGsoYSm7bZFVkNsQHIskBjHnjpdY+gOmXWMrmTel70FeRAN0aaL/udGUGTYDI/fUW2nyo3O4KHHVnDk5urKqY29+1niubZwGu9Z8ovBLpBmOQoXxW3ey5G7f+PGfQqvQ5Qc32yp0M= Original-Received: by 10.141.79.12 with SMTP id g12mr6186251rvl.182.1203553253475; Wed, 20 Feb 2008 16:20:53 -0800 (PST) Original-Received: by 10.140.135.15 with HTTP; Wed, 20 Feb 2008 16:20:53 -0800 (PST) In-Reply-To: <18363.29854.271108.937443@kahikatea.snap.net.nz> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 (Google crawlbot) 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:89756 Archived-At: On Feb 19, 2008 7:30 PM, Nick Roberts wrote: > > in any case, i *do* want to see pdb tracking included in whichever. > > as the author of the feature, i should be able to authorize its use > > wherever, and am frustrated with the twisty turns of events that have > > prevented that. > > > > If you wrote the original version, we can install that > > with papers from you alone. (Just say that you consider > > it a change to Emacs and your assignment will cover it.) > [...] > As Ken is the author of these changes, has an assignment for Emacs and is keen > to see them installed, to move things along I have installed them. yay! thanks! > My understanding is that the advantage of Pdbtrack is that you can start to > debug on the fly. There's a small example attached below using a file called > fibo.py (which I probably pinched from somewhere, but I can't remember where). > However, as I've said before I'm not a Python programmer and Ken can probably > explain better. the crucial thing is that, with an interactive language, you're much more able, and more likely, to trigger debugging whenever you need to do so. the idea of having to switch to a special debugging environment (like gdb/gud) is a holdover from dealing with compiled code, and means you have to restart your program and resurrect the context where the problem happened. that often is a terrible hassle and loss of context. (imagine if you had to restart emacs to debug elisp. pdb tracking is the minimalist equivalent of edebug.) instead, pdb tracking makes debugger sensitivity available at every moment. the way you've implemented it, you put the comint hook only in the python-shell. the thing is, python programs aren't only run from python-shell. in fact, many python programs and servers are usually launched as regular commands, from bash shells. in python-mode.el, pdb tracking is hooked into all comint shells, and i would like to see that same thing in the python.el version. the way i most commonly use it, nowadays, is with python-based servers, like zope, which i launch as bash shell commands in non-forking "development" mode. the server runs normally until i arrange for a pdb.set_trace() to be hit, or i have it rigged to go to pdb for uncaught exceptions. in many cases i can edit code to add the set_trace() on the fly, in the filesystem or in application-resident storage. the debugging traces show up in the shell where i launched the server, and pdb tracking kicks in. there's a provision, not yet ported to the python.el version, which handles the case where the traced script doesn't actually live in the local filesystem. in this case, when pdb tracking is unable to find the script according to indicated path, it looks for a python-mode buffer with the same file name as the target, and uses that. this is a very general approach that works with stored or remote procedures in any application, not just zope. there's one further, much smaller tweak to add. more recent versions of python-mode (than the one you evidently were using) provide for recursive debugging, where you can delve into an arbitrary statement in the midst of debugging something else, and return to where you started. the regular expressions need to be adjusted to account for that situation (i have wanted to mention this approach to instrumenting emacs as a debugging environment for a long time, particularly at times when rejiggering of gud was being discussed. pdb tracking features are pretty minimal - it's just maintenance of the arrow overlay in the target file, as you step through - but the original implementation was just 150 lines of code, and over half of those were comments. gud does a lot more - but it's many orders of magnitude larger. i think this more loosely coupled approach may be a lot more useful and efficient particularly for interpreted languages.) > Note that python-shell is similar to run-python and one should probably > eventually subsume the other. > > So, all credit to Ken, complaints to me... no, what the heck, give Ken your > grief too! > > More seriously, this is only on the trunk and I can always revert these changes > if there are problems. > > Enjoy! > > Ken, > > Have you got write access yet? yes. i'm hoping to have time to work on this more, hopefully tomorrow or friday. i'd like to put in all the features i've described (though i certainly wouldn't mind someone else beating me to it, if anyone is so inclined), and check them in to the trunk. let me know if you there are any objections. also, i've also been talking with barry and skip, who would also be interested in seeing the python mode versions converge. i do see that python-mode.el is actively maintained - it's current with the pre-release python 3.0, and it looks like a much more complete language mode than python.el. would there be interest in helping to get this convergence? is python.el actively maintained, and if so, would the maintainers be interested in helping consolidate the versions? ken > -- > Nick http://www.inet.net.nz/~nickrob > --------------------------------------- > > # Fibonacci numbers module (fibo.py) > > def fib (n): # write Fibonacci series up to n > a, b = 0, 1 > while b < n: > print b, > a, b = b, a+b > > def fib2 (n): # return Fibonacci series up to n > result = [] > a, b = 0, 1 > while b < n: > result.append (b) > a, b = b, a+b > return result > > --------------------------------------- > > Pdbtrack: > > M-x python-shell (note doesn't use run-python) > > Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25) > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import pdb > >>> import fibo > >>> pdb.run ("fibo.fib(1000)") > > (1)() > (Pdb) b fibo.py:5 > Breakpoint 1 at /home/nickrob/python/fibo.py:5 > (Pdb) c > > /home/nickrob/python/fibo.py(5)fib() > -> while b < n: > (Pdb) > > Source should appear in buffer with overlay arrow. > -- ken http://myriadicity.net