From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29530 invoked from network); 18 Sep 2008 15:22:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Sep 2008 15:22:50 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 27006 invoked from network); 18 Sep 2008 15:22:45 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Sep 2008 15:22:45 -0000 Received: (qmail 5208 invoked by alias); 18 Sep 2008 15:22:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25686 Received: (qmail 5196 invoked from network); 18 Sep 2008 15:22:38 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Sep 2008 15:22:38 -0000 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by bifrost.dotsrc.org (Postfix) with ESMTP id 9BAFC802720D for ; Thu, 18 Sep 2008 17:22:34 +0200 (CEST) Received: by wf-out-1314.google.com with SMTP id 29so3934598wff.3 for ; Thu, 18 Sep 2008 08:22:32 -0700 (PDT) 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:references; bh=/XSBSUBTbiiSEdfHW0eXnxpTEu5f146KT3l2SaNylWE=; b=sINvhuWtw+rjiHYw3xIkmqIqgWHKE9VYWB6WbPbufl4mDVHueVSRzUrOkebkSyr/ru 8t1GWdnytYknBvnb52ZF4jKUhY2okwl+7Dm94wPmko0I/1l/Ht2i5EXe3j71ZgQuYgKk Qq8IyVqgCARCiiwWp9AlfQGKezTCuzzjlfgrQ= 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:references; b=UeIODvcagBtht/npc5T6Ko3kVZN1paDzq5XO8h0DFfHTw2xkS0U2htouUJIJ8d2YNj W17Yvls7i/0+RH0lxYwG2ZgzhPXTZPOm9uC0o9BSSyug7q5LWK/hAuhRmvIOdvzGre4k NkTzAHE6RRU4M2vNpR3DI/v+93faek8+L7kqs= Received: by 10.114.108.15 with SMTP id g15mr3903522wac.181.1221751352748; Thu, 18 Sep 2008 08:22:32 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Thu, 18 Sep 2008 08:22:32 -0700 (PDT) Message-ID: <6cd6de210809180822y15f5c97bn44844f4ef76b22a7@mail.gmail.com> Date: Thu, 18 Sep 2008 11:22:32 -0400 From: "Rocky Bernstein" To: "Peter Stephenson" Subject: Re: PATCH: source file info from PS4 Cc: "Zsh hackers list" In-Reply-To: <6cd6de210809180805w6a60f2eft222e436176659fe4@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15342_7233914.1221751352741" References: <6005.1221576641@csr.com> <6cd6de210809170939p968d36bufda419592a10cb45@mail.gmail.com> <20080918131320.2d7f88f4@news01> <6cd6de210809180805w6a60f2eft222e436176659fe4@mail.gmail.com> X-Virus-Scanned: ClamAV 0.92.1/8279/Thu Sep 18 14:42:42 2008 on bifrost X-Virus-Status: Clean ------=_Part_15342_7233914.1221751352741 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Wrote a little too soon. This patch seems to correctly report the caller whereas before it didn't. However I do think one still wants locations inside the trap. trap DEBUG is a little bit of a misnomer. trap TRACE would be more accurate and it can be used for example in profiling code. Personally I would like to be able to debug a debugger, but I realize that's perhaps a bit esoteric (although in Ruby one can have nested hooks). But suppose one wrote a profiler, or just some sort of signal handler. Don't you want to be able to debug via PS4 the same as any other code? On Thu, Sep 18, 2008 at 11:05 AM, Rocky Bernstein wrote: > Thanks for fixing. > > On Thu, Sep 18, 2008 at 8:13 AM, Peter Stephenson wrote: > >> On Wed, 17 Sep 2008 12:39:36 -0400 >> "Rocky Bernstein" wrote: >> > On Tue, Sep 16, 2008 at 10:50 AM, Peter Stephenson wrote: >> > >> > > Now we have logic for finding the source file and corresponding line >> > > number of executed code, this adds the prompt escapes %x and %I which >> > > are like %N and %i but for the file where the code was defined. >> > >> > Looks like this has problems when used inside trap DEBUG. >> >> What's happening here is that the current shell logic doesn't update line >> numbers when inside a trap, even inside nested functions. > > > Ok. Thanks for the explanation. I don't see how this gives a line number > that is larger than the number of lines in the entire program, but if the > problem is fixed this is moot. > > >> The idea is that >> you're interested in the line number of what triggered the trap; this is >> particularly true of a DEBUG trap where you might want to examine LINENO >> to >> see what's going on in the code you're debugging, and you're much less >> likely to be interested in the line number inside the trap itself. > > > If one wants the line number that triggered the trap, there are two simple > ways to get this: > 1. Save the line number in the call > trap 'int_handler $LINENO' INT > 2. Use funcfiletrace > > >> >> So the obvious fix is to make the prompt code I added take account of >> this. > > > Yes, I think this the best thing. > > >> >> >> Another possibility would be to make traps respect the EVALLINENO option, >> so that you would get the local line numbers. However, I think that's >> less >> useful. >> >> It's possible the same problem affects some of the other new features. In >> particular I think funcstack line number info for eval commands inside >> traps is going to get thoroughly confused. I think the simplest fix would >> be not to add funcstack info for eval in this case; this is sort of >> plausible since it's like the case where eval isn't keep track of its own >> line numbers, where we don't add funcstack info, and we don't add >> funcstack >> info for a trap which is like an eval without its own line number. >> Otherwise it's not currently obvious to me what the fix would be. >> >> It might be a good idea to add special variables ZSH_SOURCE_LINENO and >> ZSH_SOURCE_FILE as more readable alternatives to ${(%):-%I} and >> ${(%):-%x}. >> >> Index: Src/prompt.c >> =================================================================== >> RCS file: /cvsroot/zsh/zsh/Src/prompt.c,v >> retrieving revision 1.54 >> diff -u -r1.54 prompt.c >> --- Src/prompt.c 16 Sep 2008 15:07:16 -0000 1.54 >> +++ Src/prompt.c 18 Sep 2008 11:55:04 -0000 >> @@ -726,7 +726,8 @@ >> stradd(Rstring); >> break; >> case 'I': >> - if (funcstack && funcstack->tp != FS_SOURCE) { >> + if (funcstack && funcstack->tp != FS_SOURCE && >> + (!intrap || trapisfunc)) { >> /* >> * We're in a function or an eval with >> * EVALLINENO. Calculate the line number in >> @@ -749,7 +750,8 @@ >> bp += strlen(bp); >> break; >> case 'x': >> - if (funcstack && funcstack->tp != FS_SOURCE) >> + if (funcstack && funcstack->tp != FS_SOURCE && >> + (!intrap || trapisfunc)) >> promptpath(funcstack->filename ? funcstack->filename : >> "", >> arg, 0); >> else >> -- >> Peter Stephenson Software Engineer >> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road >> Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 >> > > ------=_Part_15342_7233914.1221751352741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Wrote a little too soon. This patch seems to correctly report the caller whereas before it didn't. However I do think one still wants locations inside the trap.

trap DEBUG is a little bit of a misnomer. trap TRACE would be more accurate and it can be used for example in profiling code. Personally I would like to be able to debug a debugger, but I realize that's perhaps a bit esoteric (although in Ruby one can have nested hooks).

But suppose one wrote a profiler, or just some sort of signal handler. Don't you want to be able to debug via PS4 the same as any other code?

On Thu, Sep 18, 2008 at 11:05 AM, Rocky Bernstein <rocky.bernstein@gmail.com> wrote:
Thanks for fixing.

On Thu, Sep 18, 2008 at 8:13 AM, Peter Stephenson <pws@csr.com> wrote:
On Wed, 17 Sep 2008 12:39:36 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 10:50 AM, Peter Stephenson <pws@csr.com> wrote:
>
> > Now we have logic for finding the source file and corresponding line
> > number of executed code, this adds the prompt escapes %x and %I which
> > are like %N and %i but for the file where the code was defined.
>
> Looks like this has problems when used inside trap DEBUG.

What's happening here is that the current shell logic doesn't update line
numbers when inside a trap, even inside nested functions.  

Ok. Thanks for the explanation. I don't see how this gives a line number that is larger than the number of lines in the entire program, but if the problem is fixed this is moot.
 
The idea is that
you're interested in the line number of what triggered the trap; this is
particularly true of a DEBUG trap where you might want to examine LINENO to
see what's going on in the code you're debugging, and you're much less
likely to be interested in the line number inside the trap itself.

If one wants the line number that triggered the trap, there are two simple ways to get this:
1. Save the line number in the call
   trap 'int_handler $LINENO'  INT
2. Use funcfiletrace



So the obvious fix is to make the prompt code I added take account of
this.

Yes, I think this the best thing.
 


Another possibility would be to make traps respect the EVALLINENO option,
so that you would get the local line numbers.  However, I think that's less
useful.

It's possible the same problem affects some of the other new features.  In
particular I think funcstack line number info for eval commands inside
traps is going to get thoroughly confused.  I think the simplest fix would
be not to add funcstack info for eval in this case; this is sort of
plausible since it's like the case where eval isn't keep track of its own
line numbers, where we don't add funcstack info, and we don't add funcstack
info for a trap which is like an eval without its own line number.
Otherwise it's not currently obvious to me what the fix would be.

It might be a good idea to add special variables ZSH_SOURCE_LINENO and
ZSH_SOURCE_FILE as more readable alternatives to ${(%):-%I} and
${(%):-%x}.

Index: Src/prompt.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/prompt.c,v
retrieving revision 1.54
diff -u -r1.54 prompt.c
--- Src/prompt.c        16 Sep 2008 15:07:16 -0000      1.54
+++ Src/prompt.c        18 Sep 2008 11:55:04 -0000
@@ -726,7 +726,8 @@
                   stradd(Rstring);
               break;
           case 'I':
-               if (funcstack && funcstack->tp != FS_SOURCE) {
+               if (funcstack && funcstack->tp != FS_SOURCE &&
+                   (!intrap || trapisfunc)) {
                   /*
                    * We're in a function or an eval with
                    * EVALLINENO.  Calculate the line number in
@@ -749,7 +750,8 @@
               bp += strlen(bp);
               break;
           case 'x':
-               if (funcstack && funcstack->tp != FS_SOURCE)
+               if (funcstack && funcstack->tp != FS_SOURCE &&
+                   (!intrap || trapisfunc))
                   promptpath(funcstack->filename ? funcstack->filename : "",
                              arg, 0);
               else
--
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


------=_Part_15342_7233914.1221751352741--