Re: edebug question - context of calling function

[David Vanderschel]

"jan" <janmar@iprimus.com.au> wrote in message
news:mailman.1915.1066445382.21628.help-gnu-emacs@gnu.org...
> "David Vanderschel" <DJV1@Austin.RR.com> 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.