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

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

[Neil Jerram]

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.  ;-)

> 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.

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?

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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

[Neil Jerram]

[I'm sorry about this email, masquerading as being from me, but
actually one that Ludovic wrote yesterday.  For some reason I didn't
receive Ludovic's email through email, but just noticed it in the web
archive.  So I was trying to reconstruct Ludovic's email in Gnus so
that I could reply to it - and accidentally sent it my mistake!]

Neil Jerram <neil@ossau.uklinux.net> claimed to write:

> 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.  ;-)
>
>> 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.
>
> 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?
>
> Thanks,
> Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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.  [...]



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> 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.

Sure.  Or the first invocation could be passed as a parameter to
`guile', as in `scripts/PROGRAM'.

> 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.

Yeah, and I think it wouldn't work either with forms within a `begin',
e.g., `(begin (set! x 1) (set! x 2) ...)'.

> 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.

As long as `C-x SPC' keeps working the same way, it's all good.  ;-)

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Anyone relying on "break-at" breakpoints?

[Neil Jerram]

This email pertains to the debugging and breakpoint infrastructure in
Guile CVS, which has so far only been released as part of my
guile-debugging package.  If you've never looked at or used this
infrastructure, you can safely skip the rest of this message.

I've been wrestling for a while with specifying and documenting
exactly how "break-at" breakpoints should behave, and have concluded
that the problem arises from how these breakpoints are defined.
Therefore I'm looking at removing them (in their current form), and
hence this email to check if anyone would be inconvenienced by that.

A break-at breakpoint is defined by a file name, a line number and a
column number, and it means that Guile should break when executing the
code from the named file whose opening parenthesis is at the specified
line and column.  It should work both if the relevant code was loaded
before the breakpoint was defined, and if the code is loaded after the
breakpoint is defined.  In other words, it's the Guile equivalent of
GDB's "break <filename>:<line>" for C.

The trouble is that Guile (unlike C) is an interactive environment.
Someone might write a first version of a function:

(define (my-func . args)
  (let ((a (car args))
        ...)
    ...))

then evaluate and try it, then decide that it works better with an
internal definition:

(define (my-func . args)
  (define (helper arg1)
    ...)
  (let ((a (car args))
        ...)
    ...))

then evaluate the new version, and so on.  Suppose that when trying
out the first version, the coder defined a break-at breakpoint at the
position of the "(let".  Then after the redefinition (and assuming the
current specification and implementation of break-at breakpoints), the
breakpoint would be in the wrong place: it would apply to the
"(define", and would not apply to the "(let" in its new position.

This is a simple example, but there are many possible variations and
complications of it (for example, lambda-constructing code, which has
the consequence that we cannot say that there is only one "correct"
version of the source code at a given time), which make finding a nice
general solution very difficult.

By way of contrast, the other kind of breakpoint ("break-in") does not
suffer from this problem, because it is defined in a way that relates
more persistently to the code (even as the code changes).  A break-in
breakpoint is defined as

  break-in <procedure-name> [<module-or-file-name>]

and means break at the start of that procedure.

It could be argued that break-at breakpoints are fine for the "static"
case - i.e. for debugging a program and not changing it at the same
time - and hence we should keep them for this.  But I'd much rather
develop a better conceptual solution that works equally well for both
the static and interactive cases.

Therefore, I'm planning to simply drop "break-at" breakpoints (and the
associated <location-trap> trap), and then to reconsider the scenarios
for which I thought "break-at" was the solution, to work out better
solutions instead.

If there are scenarios that you (anyone!) are actually using and
relying on, please let me know, so that I can make sure that I have an
alternative solution ready for you.  If you have any questions,
suggestions or concerns about all this, please let me know those too.

Thanks for reading; I hope it all made some kind of sense. :-)

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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

[Ludovic Courtès]

Hi Neil,

Disclaimer: I'm not too familiar with the debugging infrastructure and
I've never used `break-at'.  But...

Neil Jerram <neil@ossau.uklinux.net> writes:

> By way of contrast, the other kind of breakpoint ("break-in") does not
> suffer from this problem, because it is defined in a way that relates
> more persistently to the code (even as the code changes).  A break-in
> breakpoint is defined as
>
>   break-in <procedure-name> [<module-or-file-name>]
>
> and means break at the start of that procedure.

That looks nice (I suppose it could also perform better than
`scan-source-whash'), but would "let" count as a <procedure-name> in
your example?  If so, how could we specify the scope referred to?

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi Neil,
>
> Disclaimer: I'm not too familiar with the debugging infrastructure and
> I've never used `break-at'.  But...

Well thank you for reading through!

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> By way of contrast, the other kind of breakpoint ("break-in") does not
>> suffer from this problem, because it is defined in a way that relates
>> more persistently to the code (even as the code changes).  A break-in
>> breakpoint is defined as
>>
>>   break-in <procedure-name> [<module-or-file-name>]
>>
>> and means break at the start of that procedure.
>
> That looks nice (I suppose it could also perform better than
> `scan-source-whash'), but would "let" count as a <procedure-name> in
> your example?  If so, how could we specify the scope referred to?

A priori, no, "let" wouldn't count as a procedure name.  The break-in
invocation means to break when evaluating the first form in the
relevant procedure's code, whatever that form happens to be.

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.

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?

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> 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.  ;-)

> 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.

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?

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user