From: Neil Jerram <neil@ossau.uklinux.net>
To: Guile Users <guile-user@gnu.org>
Subject: Re: Anyone relying on "break-at" breakpoints?
Date: Fri, 26 Oct 2007 19:26:35 +0100 [thread overview]
Message-ID: <871wbhenqc.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <87zly613fw.fsf@laas.fr> (Ludovic Courtès's message of "Fri, 26 Oct 2007 14:10:59 +0200")
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
next prev parent reply other threads:[~2007-10-26 18:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 21:14 Anyone relying on "break-at" breakpoints? Neil Jerram
2007-10-26 12:10 ` Ludovic Courtès
2007-10-26 18:26 ` Neil Jerram [this message]
2007-10-27 9:33 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2007-10-28 20:54 Neil Jerram
2007-10-28 20:57 ` Neil Jerram
2007-10-28 21:24 ` Neil Jerram
2007-10-29 8:45 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871wbhenqc.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).