From: Volkan YAZICI <yazicivo@ttnet.net.tr>
Cc: guile-user@gnu.org
Subject: Re: guile-debugging and breakpoints
Date: Sun, 14 Jan 2007 11:38:00 +0200 [thread overview]
Message-ID: <20070114093800.GB1343@alamut> (raw)
In-Reply-To: <87r6tyifqi.fsf@ossau.uklinux.net>
On Jan 14 01:01, Neil Jerram wrote:
> With Guile 1.8 or CVS, I find that the breakpoint doesn't even work
> the first time! I'm still looking into that.
I use Guile from cvs tip too. And after you asked for "Where did you
place the new breakpoint?" I realized that the problem is with putting
the breakpoint on an IF s-exp. IMHO, more importantly, what are the
available places that we can safely place a breakpoint. For instance,
in (define (foo ...)) or (define foo (lambda ...)) example, where
should I place my breakpoint to make it stop at FOO calls. Maybe some
words about this in the gds-tutorial.txt would be nice.
> > I don't think there's any use case for setting many breakpoints in a
> > region. Because, once user gets stopped in the first breakpoint of the
> > beginning of a region of breakpoints, he/she can move forward by
> > stepping. There's no need to stop at the next s-exp.
>
> OK, you've persuaded me on this - but I'm not sure it addresses the
> whole problem. I still think it might be useful to be able to set a
> breakpoint on a procedure by doing C-x SPC anywhere in the procedure's
> definition - which conflicts with your backward-up-list
> interpretation. What do you recommend?
What about defining a new `set' of bindings for placing a breakpoint:
;;; A generic internal method to set a breakpoint.
(define (gds-set-breakpoint type) ...)
;;; Set a breakpoint to the current s-exp cursor is currently in.
;;; Example binding: C-c C-b s
(define (gds-set-breakpoint-on-sexp)
(gds-set-breakpoint 's-exp))
;;; Set a breakpoint to the outmost DEFINE s-exp.
;;; Example binding: C-c C-b d
(define (gds-set-breakpoint-on-def)
(gds-set-breakpoint 'def))
BTW, is it possible to handle exceptions in a more fancy way. For
instance:
(define (inc n) (+ n 1))
(inc "str")
;;; Evaluating in current module (guile-user)
EXCEPTION: wrong-type-arg ("+" "Wrong type argument in position ~A:
~S" (1 "str") ("str"))
=> unhandled-exception-in-evaluation
Yes, it's not possible to make GDS understand all of the thrown
exceptions, but at least we should be able to place some hooks for the
known exceptions. (Like in this example, wrong-type-arg exception.)
IMHO, we can at least use OBJECT->STRING to place given arguments into
the error string and print whole information in a more fancy style.
If you agree on this idea, I'm volunteered to prepare a patch for this
if you'd give me an example about how can I place such a hook. (And
this will be the only step to take to make people be able to place
their own fancy-exception-printing handler hooks.)
Regards.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2007-01-14 9:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-24 1:48 guile-debugging and breakpoints Volkan YAZICI
2006-12-29 2:29 ` Neil Jerram
2007-01-10 15:33 ` Volkan YAZICI
2007-01-14 1:01 ` Neil Jerram
2007-01-14 9:38 ` Volkan YAZICI [this message]
2007-01-10 15:45 ` Volkan YAZICI
2007-01-14 1:30 ` Neil Jerram
2007-01-14 9:03 ` Volkan YAZICI
2007-01-14 10:21 ` Neil Jerram
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=20070114093800.GB1343@alamut \
--to=yazicivo@ttnet.net.tr \
--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).