Re: Anyone relying on "break-at" breakpoints?

[Neil Jerram]

Ludovic wrote:

> Hi,
>
> Neil Jerram <address@hidden> writes:
>
>> There are (at least) three possibly interesting requirements that this
>> doesn't cover.  Right now I'm still wondering about these, so ideas
>> are welcome.
>>
>> 1. The Guile application is going to load a file that contains
>>    directly-executed code as well as procedure definitions, and you
>>    want to set a breakpoint (ahead of time) on some of the
>>    directly-executed code.
>
> But this ("directly-executed" code) is bad style anyway.  ;-)

Well there has to be some directly executed code somewhere, or else
nothing will happen.  But I agree that it might be reasonable to
expect any lexically non-trivial block of code to be defined as a
procedure first.

In that case, the requirement is for procedure-based breakpoints to
become effective before the procedure is called, even when called from
the same file as that that defined the procedure.

>> 2. You want to set a breakpoint somewhere in the middle of a complex
>>    procedure, not right at the beginning of it.
>>
>> 3. You're using Guile interactively (e.g. using the GDS interface in
>>    Emacs) and want to step through the evaluation of some code (which
>>    isn't a procedure definition).
>>
>> I think your question was aiming at (2) - is that right?
>
> Exactly.

Well I haven't tried this at all yet, but I'm wondering about a form
of specification like

(break-in <proc-name> '(let if string-append))

- which would mean to break at the start of a string-append call that
is lexically within an (if ...), which is itself lexically within a
(let ...).

Something like this might work for internal definitions, too.

> But wasn't `break-at' useful when, e.g., hitting `C-x SPC' in an Emacs
> buffer (GDS)?  Or probably it works differently because the code is not
> loaded into the GDS "server" from the file you're editing in Emacs,
> right?

Yes, it certainly was useful in the case where you're evaluating some
scratch code and want to step through it (e.g. the appended example
from the GDS tutorial), so something like that needs to carry on
working.

I have two possibilities in mind for this.  (1) is for C-x SPC to
appear to work exactly as it has in the past, but not actually to send
a `break-at' instruction to Guile.  Instead, the positions of the
breakpoints are sent along with the code to be evaluated, and the
gds-client code sets the 'breakpoint source property in all the right
places, then evaluates the code.  (2) is to enhance the gds-eval*
function so that a C-u prefix argument will cause them to set the
'breakpoint source property on the start of the code to be evaluated.

Regards,
        Neil


=== from guile-debugging's gds-tutorial.txt ===

;; ** Breakpoints

;; Before evaluating Scheme code from an Emacs buffer, you may want to
;; set some breakpoints in it.  With GDS you can set breakpoints in
;; Scheme code by typing `C-x SPC'.
;;
;; To see how this works, select the second line of the following code
;; (the `(format ...)' line) and type `C-x SPC'.

(for-each (lambda (x)
            (format #t "~A cubed is ~A\n" x (* x x x)))
          (iota 6))

;; The two opening parentheses in that line should now be highlighted
;; in red, to show that breakpoints have been set at the start of the
;; `(format ...)' and `(* x x x)' expressions.  Then evaluate the
;; whole for-each expression by typing `C-M-x' ...
;;
;; In the upper half of your Emacs, a buffer appears showing you the
;; Scheme stack.  [...]