guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging with PSD (trace)


From: Neil Jerram
Subject: Re: Debugging with PSD (trace)
Date: 28 Jun 2001 18:52:53 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Bill" == Bill Schottstaedt <address@hidden> writes:

    Bill> Speaking of the debugging stuff, I have a question about
    Bill> trace; currently it seems to be dependent on repl-stack in
    Bill> boot-9.scm scm-style-repl; in my application I'm running my
    Bill> own repl in a text widget, so I don't use top-repl normally,
    Bill> but that means that trace is not operational.  I tried
    Bill> wrapping (start-stack 'repl-stack ...) around the in-coming
    Bill> form, but that appeared to be a no-op; I then went down to
    Bill> scm_start_stack, but got nowhere there either. Any
    Bill> suggestions?  (I use the current guile debugger by setting
    Bill> up a soft port for both input and output -- my request there
    Bill> would be for something like gdb's info locals.  The recent
    Bill> addition of file name/line numbers to the stack trace was a
    Bill> huge improvement).

I presume by "trace" you mean stack trace, not the '(trace ...)'
facility?

As far as I understand start-stack, the point of the ID
(i.e. 'repl-stack) is to tell save-stack how to narrow that stack when
an error occurs.  'Narrowing' means cutting out a load of frames that
it, in its wisdom, believes would not be of interest to you (which of
course it could get quite wrong!).

So what do you mean by "trace is not operational"?  Is it that the
narrowing process has actually cut away all the frames, so that
there's nothing left?

        Neil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]