From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "David Vanderschel" Newsgroups: gmane.emacs.help Subject: Re: edebug question - context of calling function Date: Fri, 24 Oct 2003 07:16:17 -0500 Organization: hardly ever ;-) Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <0tWdnZ-zD5A5zBKiRTvUqg@texas.net> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1066998933 15944 80.91.224.253 (24 Oct 2003 12:35:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2003 12:35:33 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Oct 24 14:35:31 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AD1AB-0008Rk-00 for ; Fri, 24 Oct 2003 14:35:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AD16A-0005Ek-6x for geh-help-gnu-emacs@m.gmane.org; Fri, 24 Oct 2003 08:31:22 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!nntp.cs.ubc.ca!nntp-relay.ihug.net!ihug.co.nz!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.texas.net!news.texas.net.POSTED!not-for-mail Original-NNTP-Posting-Date: Fri, 24 Oct 2003 07:16:11 -0500 Original-Newsgroups: gnu.emacs.help X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Original-Lines: 92 Original-X-Trace: sv3-N1AMpk0/2E81+j/ROzV6PRd8gcrOsy6SWANBUEKxQ5Jk/O4BE8Xd1TjMtHFbLQD6yoy0FK/zdRH3IAK!q0XDywvdZvFS1B+s0WAhht9dOK8IwT/s2T0S7rzzQntGpIpyYmLvTa51u51x Original-X-Complaints-To: abuse@texas.net X-DMCA-Complaints-To: abuse@texas.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Original-Xref: shelby.stanford.edu gnu.emacs.help:117579 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:13511 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13511 "jan" wrote in message news:mailman.1915.1066445382.21628.help-gnu-emacs@gnu.org... > "David Vanderschel" writes: > > I think you do understand me correctly. > > Unfortunately, I often reuse the same local > > variables (eg., i, j, x, ...). > I'm guessing that i and j are iteration variables, > and x is a position on an x-axis. If not, I think > you need to use more descriptive variable names, and > use dabbrev-expand (M-/) or hippie-expand to save > yourself the extra typing. I did not post in order to get advice on programming style. When I am using a variable intensely and locally, I personally find that the code is easier to read if the symbol for that variable is short - more like doing mathematics. I believe that for such variables, it is better to learn the usage of the short symbol than to clutter the code with repetitious occurrences of a symbol which persists in always 'explaining' itself. When appropriate, I do put an extensive comment where the variable is declared, explaining how it is used. (Actually, for something like an array index, not even such an explanation is needed. Eg., (loop for i to 20 do (aset v i ...)). 'i' is a variable I am especially fond of reusing as an index variable in a loop.) For more global things where usage is not locally intensive but thinly distributed, I _do_ use long, carefully chosen names which suggest the function without much extra documentation. This also avoids naming conflicts in the not-very-hierarchical name space offered by emacs. > > I was also interested in the calling context in > > the sense of "Among multiple possible invocations > > in the calling program, which invocation of of the > > function which noticed the condition caused this > > break." I guess you are correct that I have to > > move the logic which catches the inconsistency up > > a level. But there is no one nice place to put it > > for the bug I am chasing now. > If you can reproduce the bug consistently, just use > the backtrace to find out which function to move the > breakpoint up into. I already know which is the calling the function. The problem is that that code contains multiple invocations of the function which notices the error condition, and I want to know which _one_ of those invocations made the call exhibiting the problem. In the extreme and when it is possible for the called function to return anyway, I can instrument the calling function myself, by placing a check after each invocation to see if the error condition arose during processing by the called function. (It can set a flag when the error condition is seen.) However, I was hoping that one would not need to go to such lengths. I am familiar with other debuggers which allow you to proceed up and down the stack of call frames, looking at context (including location of the call in each calling program) in a whole hierarchy of calling functions. I just expected such capability in edebug and was trying to find out how to exercise it. However, I am willing to accept that the capability is not there. > Otherwise, if you're willing to recompile emacs then > the following function combined with the backtrace > should give you all the info you need to piece > together what's happening. Unfortunately, I am not in a position to recompile emacs. However, even if I were, I fear that I have missed the point of jan's edebug-symbol-values. I have no difficulty getting edebug to show me symbol values as it is now. Indeed, it already has an "eval" function (bound to 'e'). (Actually, I can usually just put the cursor on an instance of a variable I want the value of and hit C-x e.) The eval function does correctly evaluate the variables of the calling function when I have not reused them in the called function; but it does not help to find the context in the calling program from which the invocation occurred. Regards, David V.