From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9735 invoked by alias); 5 Aug 2008 03:32:05 -0000 Received: (qmail 9725 invoked by uid 22791); 5 Aug 2008 03:32:04 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Aug 2008 03:31:26 +0000 Received: from HOME-C4E4A596F7 ([77.126.7.152]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K53008P8Z3SDR00@i-mtaout6.012.net.il> for gdb-patches@sources.redhat.com; Tue, 05 Aug 2008 06:31:05 +0300 (IDT) Date: Tue, 05 Aug 2008 03:32:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: <20080805020754.GA17244@caradoc.them.org> X-012-Sender: halo1@inter.net.il To: Daniel Jacobowitz Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <1216653969.31797.6.camel@localhost.localdomain> <20080726173508.GA16470@caradoc.them.org> <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@caradoc.them.org> <20080805020754.GA17244@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00070.txt.bz2 > Date: Mon, 4 Aug 2008 22:07:54 -0400 > From: Daniel Jacobowitz > Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com > > On Mon, Aug 04, 2008 at 10:48:46PM +0300, Eli Zaretskii wrote: > > When executing the @code{python} command, Python exceptions > > uncaught within the Python code are translated to calls to > > @value{GDBN} error-reporting mechanism. If the command that called > > @code{python} does not handle the error, @value{GDBN} will > > terminate it and print an error message containing the Python > > exception name, the associated value, and the Python call stack > > backtrace at the point where the exception was raised. Example: > > I think we've almost got it. The only problem I see with the above > text is that it's focused on user commands, both "python" and others. > This fits with the "Canned Sequences of Commands" usage which is what > the first patch implements, but if we can say it more generally it may > continue to be true as more patches go in. Here's some other > scenarios I heard mentioned in conversation today: > > - Tab completion. Python code might be invoked when the user hits Tab > in the middle of an expression. > > - "gdb --python", which Tom has implemented on the branch - no CLI > interpreter involved, GDB just executes a Python script. > > - If Python code is used to discover some information about a stack > frame, it might be invoked every time the program stops. > > So that gives me a paragraph like this, which I think is accurate. > Does this look OK to you? > > When executing Python code, uncaught Python exceptions are translated > to calls to the @value{GDBN} error-reporting mechanism. If > @value{GDBN} does not handle the error, it will terminate the current > command and print an error message containing the Python exception > name, the associated value, and the Python call stack backtrace at the > point where the exception was raised. Example: I'm not sure this change is for the best: you've eliminated only one of the two uses of "command" in this text, which just obfuscates the text a little (what is it exactly in GDB that does not handle the error, and if it isn't a command that invoked "python", why do we terminate a command?). I think trying to say the truth, all the truth, and nothing but the truth is not the right attitude when writing software documentation. So, on balance, I like my text better.