From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22347 invoked from network); 13 Aug 2008 19:43:13 -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,WEIRD_PORT autolearn=no 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; 13 Aug 2008 19:43:13 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 19787 invoked from network); 13 Aug 2008 19:42:49 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Aug 2008 19:42:49 -0000 Received: (qmail 5191 invoked by alias); 13 Aug 2008 19:42:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25447 Received: (qmail 5153 invoked from network); 13 Aug 2008 19:42:23 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 13 Aug 2008 19:42:23 -0000 Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by bifrost.dotsrc.org (Postfix) with ESMTP id A2C9380EA0B3 for ; Wed, 13 Aug 2008 21:42:15 +0200 (CEST) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20080813194215.SDZC10791.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Wed, 13 Aug 2008 20:42:15 +0100 Received: from pws-pc ([81.107.40.67]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20080813194215.QEPY18637.aamtaout04-winn.ispmail.ntl.com@pws-pc> for ; Wed, 13 Aug 2008 20:42:15 +0100 Date: Wed, 13 Aug 2008 20:42:12 +0100 From: Peter Stephenson To: "Zsh hackers list" Subject: Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files) Message-ID: <20080813204212.4c72c96a@pws-pc> In-Reply-To: <6cd6de210808121700kf500ea6p9b3eed0fefadfc8@mail.gmail.com> References: <6cd6de210808121700kf500ea6p9b3eed0fefadfc8@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8027/Wed Aug 13 20:31:07 2008 on bifrost X-Virus-Status: Clean On Tue, 12 Aug 2008 20:00:40 -0400 "Rocky Bernstein" wrote: > I've attached the little test program called linebug.sh. It doesn't do > any "source"'ing. rocky-patch.out contains the output given with the > patch I submitted. functrace.out contains output using $functrace and > funcsourcetrace.out contains output using $funcsourcetrace.out. As I said, deciding what's in the calling context and what's in the current context is difficult. We've got something that consistently tracks only the calling context; it seems what we need to end up with is a mixture with the next level up. Let's analyse the differences in one of the key bits, in a function call; here they are in parallel: functrace funcsourcetrace rocky where we are foo:1 ./linebug.sh:1 linebug.sh:10 print_stack ./linebug.sh:16 ./linebug.sh:9 linebug.sh:16 foo In the first line, - foo:1 means "we (print_stack) were called from the first line in the function foo" - ./linebug.sh:1 means "the definition of print_stack is at line 1 in linebug.sh" - linebug.sh:10 means "the caller of print_stack is at line 10 in linebug.sh, regardless of where the line in the function is". In the second line, - ./linebug.sh:16 means "our own caller (foo) was called here"; this is a script, not a function, so it's a filename, not a function name. - ./linebug.sh:9 means "foo was defined starting here" - ./linebug.sh:16 means "our own caller was run at this line in this file" So the number Rocky wants for the function context is actually the first line from functrace plus the second line from funcsourcetrace (which is the point at which line number 0 of foo occurs). So to do this consistently for functions, it looks like we need an array that keeps the file from the next level up in funcsourcetrace (the function might be defined in a different file, and that's what we need to get the right line number) and adds that line number to the line number in the immediately calling context. This should be doable (without too much additional help, anyway) entirely within a new function (corresponding to a new array) in the parameter module. The major decision is whether the immediate caller is a function, in which case do the addition as above, or not, in which case just report the current functrace output. The functrace output should be fine for source'd files, too. I'll have a look at this when I get back (unless I get bored on holiday). -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/