* repl debugger impressions
@ 2010-10-15 19:07 Mike Gran
2010-10-17 13:10 ` Ludovic Courtès
2010-10-19 18:33 ` Andy Wingo
0 siblings, 2 replies; 4+ messages in thread
From: Mike Gran @ 2010-10-15 19:07 UTC (permalink / raw)
To: guile-devel
Hey all-
So I've been banging on the debugger for a few days now.
Let me start off by saying that you did a great job. It
is pretty amazing.
But, I have a few suggestions. ;-)
I think, in general, there are too many hexadecimal addresses
in the output. For example
-> Step into #<frame a1b2c3d4 #<procedure ...
IMHO, Unless that hex number can be decoded via some command, it
is just noise.
Also, there is one feature that would make the debugger much
more valuable to me. If, after every ",step" or ",next", it
printed out the filename:line:column, that'd be helpful. I
hacked on it a little, and I think it would be easy to do.
And, if that filename:line:column were delimited by something
unique, for example curly braces, it would then be easy enough
to write an Emacs minor mode to pick up that filename:line:column
from the Geiser or Shell window and automatically center another
window on that file at that source line, the way the GDB GUD mode
does.
What do you think?
Thanks,
Mike Gran
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: repl debugger impressions
2010-10-15 19:07 repl debugger impressions Mike Gran
@ 2010-10-17 13:10 ` Ludovic Courtès
2010-10-17 18:00 ` Jose A. Ortega Ruiz
2010-10-19 18:33 ` Andy Wingo
1 sibling, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2010-10-17 13:10 UTC (permalink / raw)
To: guile-devel
Hi Mike,
Mike Gran <spk121@yahoo.com> writes:
> -> Step into #<frame a1b2c3d4 #<procedure ...
>
> IMHO, Unless that hex number can be decoded via some command, it
> is just noise.
It’s not just noise because it allows you to distinguish, e.g., between
same-named procedures. As for frame addresses, it allows you to know
whether you’re actually going down the stack or not, for instance (GDB
gives that info too.) So I find it quite valuable.
Now, perhaps it could be formatted in a more human-readable way?
> Also, there is one feature that would make the debugger much
> more valuable to me. If, after every ",step" or ",next", it
> printed out the filename:line:column, that'd be helpful. I
> hacked on it a little, and I think it would be easy to do.
+1
> And, if that filename:line:column were delimited by something
> unique, for example curly braces, it would then be easy enough
> to write an Emacs minor mode to pick up that filename:line:column
> from the Geiser or Shell window and automatically center another
> window on that file at that source line, the way the GDB GUD mode
> does.
+1
I think we need input from the Gesier Meister here. :-)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: repl debugger impressions
2010-10-17 13:10 ` Ludovic Courtès
@ 2010-10-17 18:00 ` Jose A. Ortega Ruiz
0 siblings, 0 replies; 4+ messages in thread
From: Jose A. Ortega Ruiz @ 2010-10-17 18:00 UTC (permalink / raw)
To: guile-devel
On Sun, Oct 17 2010, Ludovic Courtès wrote:
[...]
>> And, if that filename:line:column were delimited by something
>> unique, for example curly braces, it would then be easy enough
>> to write an Emacs minor mode to pick up that filename:line:column
>> from the Geiser or Shell window and automatically center another
>> window on that file at that source line, the way the GDB GUD mode
>> does.
>
> +1
>
> I think we need input from the Gesier Meister here. :-)
Well, the current format in which frame information is printed (when
requested by ,frame) in case of errors is already enough for Geiser to
jump to the error location: just try M-g n (next-error) when an
evaluation error happens, or set geiser-guile-jump-on-debug-p to t to
make jumping (after an evaluation outside the REPL) the default
behaviour (as Ludo knows, being the one who had the idea :)). To support
the new debugger, all that is needed is a way to distinguish whether one
entered the debugger as a result of an error (so that one's interested
in the current frame) or because of a breakpoint (and then the relevant
source info corresponds to the _next_ frame). I think Andy's planning to
make that information easily available at some point, and i was waiting
for that to add full support to Guile's debugger in geiser (including
things like setting a breakpoint in the current line/function &c.).
(I'm just being a little lazy, because i know it's already probably
possible to snarf that information from the repl object, but it's a bit
convoluted.)
Cheers,
meister jao
--
I want to stay as close to the edge as I can without going over. Out on the
edge you see all kinds of things you can't see from the center.
-Kurt Vonnegut, Jr.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: repl debugger impressions
2010-10-15 19:07 repl debugger impressions Mike Gran
2010-10-17 13:10 ` Ludovic Courtès
@ 2010-10-19 18:33 ` Andy Wingo
1 sibling, 0 replies; 4+ messages in thread
From: Andy Wingo @ 2010-10-19 18:33 UTC (permalink / raw)
To: Mike Gran; +Cc: guile-devel
On Fri 15 Oct 2010 21:07, Mike Gran <spk121@yahoo.com> writes:
> I think, in general, there are too many hexadecimal addresses
> in the output. For example
>
> -> Step into #<frame a1b2c3d4 #<procedure ...
Agreed, this is terrible. It should be understandable by the user;
e.g. "step from ice-9/boot-9.scm:2936", or something like that.
> Also, there is one feature that would make the debugger much
> more valuable to me. If, after every ",step" or ",next", it
> printed out the filename:line:column, that'd be helpful. I
> hacked on it a little, and I think it would be easy to do.
Yes, you are right here also.
> And, if that filename:line:column were delimited by something
> unique, for example curly braces, it would then be easy enough
> to write an Emacs minor mode to pick up that filename:line:column
> from the Geiser or Shell window and automatically center another
> window on that file at that source line, the way the GDB GUD mode
> does.
Yes, also agreed, though I would have the pattern be something like
<Beginning of line>foo.scm:line:col: ... .
Cheers,
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-10-19 18:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-15 19:07 repl debugger impressions Mike Gran
2010-10-17 13:10 ` Ludovic Courtès
2010-10-17 18:00 ` Jose A. Ortega Ruiz
2010-10-19 18:33 ` Andy Wingo
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).