Ditching (debug-enable 'backwards) ?

Ditching (debug-enable 'backwards) ?

[Neil Jerram]

Does anyone use (debug-enable 'backwards) and have a good reason for
keeping it?

In my view, it makes documenting the debugger harder, is likely to
introduce bugs in the debugger code (if there aren't any there
already), and is simply pointless, so I propose to get rid of it.
(With deprecation, of course ...)

(Cf. the recent discussion on options on gnucash-devel.  I'd say this
is a classic example of a pointless option whose only rationale is
that someone wanted to avoid making a decision.)

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Ditching (debug-enable 'backwards) ?

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 27 Oct 2002 13:04:41 +0000

   Does anyone use (debug-enable 'backwards) and have a good reason for
   keeping it?

   In my view, it makes documenting the debugger harder, is likely to
   introduce bugs in the debugger code (if there aren't any there
   already), and is simply pointless, so I propose to get rid of it.
   (With deprecation, of course ...)

it is only pointless if you buy into a philosophy where you understand
all points a priori.

you need not document it more than saying "there is an output option
... so in the example output below just stand on your head to get the
full effect".  generally, orthogonal features can/should be documented
in a likewise orthogonal style (else you get combinatorial explosion).

i see about half a dozen places in the code where this option manifests,
all of them highly stable.  (how can an option introduce bugs -- only
uncareful people can do that. :-)

thi


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

Re: Ditching (debug-enable 'backwards) ?

[Neil Jerram]

    Neil>    Does anyone use (debug-enable 'backwards) and have a good
    Neil>    reason for keeping it?

>>>>> "Thien-Thi" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    Thien-Thi> it is only pointless if you buy into a philosophy where you understand
    Thien-Thi> all points a priori. [...]

I'll take that as a `no', then.

Things need a reason to be there now; if and when further points arise
in the future, we can reconsider.

        Neil



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

Re: Ditching (debug-enable 'backwards) ?

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 27 Oct 2002 19:00:02 +0000

   I'll take that as a `no', then.

it is a no from one user, not all users.

   Things need a reason to be there now; if and when further points
   arise in the future, we can reconsider.

the reason may not come from me or you, from a one-day strawman poll.
(i'm reminded of the douglas adams book where the notice to bulldoze the
earth was posted in a basement behind a filing cabinet somewhere. :-)

try not to get sucked into the proprietary mindset ("it's my code i can
piss on it if i want"), even as you do good work enhancing the system.
the nice hack is to build w/o destroying, because you save someone from
having to rebuild that feature later.

thi


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

Re: Ditching (debug-enable 'backwards) ?

[Neil Jerram]

>>>>> "Thien-Thi" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    Thien-Thi> it is a no from one user, not all users.

That's OK - I understood that.

    Thien-Thi> the reason may not come from me or you, from a one-day strawman poll.
    Thien-Thi> (i'm reminded of the douglas adams book where the notice to bulldoze the
    Thien-Thi> earth was posted in a basement behind a filing cabinet somewhere. :-)

Hang on - when did I say one day?  Although I didn't say so (for which
apologies), my intention was (and is) to leave a couple of weeks for
anyone to respond.

    Thien-Thi> try not to get sucked into the proprietary mindset ("it's my code i can
    Thien-Thi> piss on it if i want"), even as you do good work enhancing the system.
    Thien-Thi> the nice hack is to build w/o destroying, because you save someone from
    Thien-Thi> having to rebuild that feature later.

Please believe that I never think like this.  Guile is nothing without
its users.

        Neil



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

Re: Ditching (debug-enable 'backwards) ?

[Keith Wright]

> From: Thien-Thi Nguyen <ttn@giblet.glug.org>
> 
>    From: Neil Jerram <neil@ossau.uklinux.net>
> 
>    Does anyone use (debug-enable 'backwards) and have a good
>    reason for keeping it?

It looks like cruft to me.

> it is only pointless if you buy into a philosophy where you
> understand all points a priori.

I buy a philosophy that says you don't throw in things you don't
understand, but I don't buy Philosophy to the point that I try
to make a Zen koan out of every simple programming question.

> ...  generally, orthogonal features can/should be documented in
> a likewise orthogonal style

Maybe the orthogonal way to do this would be to provide a way
to specify a script to be run on the output before displaying
it.  The you can run your debug output through 'tac', 'grep',
'tee', or banner, at your option.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---


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

Re: Ditching (debug-enable 'backwards) ?

[Marius Vollmer]

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

> Does anyone use (debug-enable 'backwards) and have a good reason for
> keeping it?

Hmm.  I'd say we should only remove it when there is significant cost
associated with it.  Since we already have it, we might as well keep
it.  Maybe it will make someone happy. :-)

> In my view, it makes documenting the debugger harder,

It would good enough to just document the default case and only
mention somewhere that the backtrace can also be displayed backwards
but that the documentation assumes that it is not being done.

> is likely to introduce bugs in the debugger code (if there aren't
> any there already),

Is that so?  The 'backwards' option should only matter during display
and we already have that code, right?


On the other hand, if you need to write new display code for the
debugger and the backwards option makes that significantly harder, I'd
say it is OK to remove it.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Ditching (debug-enable 'backwards) ?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> Does anyone use (debug-enable 'backwards) and have a good reason for
    >> keeping it?

    Marius> Hmm.  I'd say we should only remove it when there is significant cost
    Marius> associated with it.  Since we already have it, we might as well keep
    Marius> it.  Maybe it will make someone happy. :-)

To be more precise, what I don't like about 'backwards is that it
changes how the displayed frames are _numbered_:

guile> (let ((x 1) (y "e")) (/ 2 (+ x y)))

Backtrace:
In unknown file:
   ?: 0* (let ((x 1) (y "e")) (/ 2 (+ x y)))
   ?: 1  [/ 2 ...
   ?: 2*  [+ 1 "e"]

<unnamed port>: In procedure + in expression (+ x y):
<unnamed port>: Wrong type argument: "e"
ABORT: (wrong-type-arg)

guile> (debug-enable 'backwards)
(show-file-name #t stack 20000 debug backtrace depth 20 maxdepth 1000 frames 3 indent 10 width 79 backwards procnames cheap)
guile> (let ((x 1) (y "e")) (/ 2 (+ x y)))

Backtrace:
In unknown file:
   ?: 0* [+ 1 "e"]
   ?: 1  [/ 2 ...
   ?: 2* (let ((x 1) (y "e")) (/ 2 (+ x y)))

<unnamed port>: In procedure + in expression (+ x y):
<unnamed port>: Wrong type argument: "e"
ABORT: (wrong-type-arg)

I have no objection to frames appearing in reverse order, but I prefer
that they were then _numbered_ like this (artist's impression):

Backtrace:
In unknown file:
   ?: 2* [+ 1 "e"]
   ?: 1  [/ 2 ...
   ?: 0* (let ((x 1) (y "e")) (/ 2 (+ x y)))

(As a side point, note that indentation is not as informative when
displaying frames backwards.)

    >> is likely to introduce bugs in the debugger code (if there aren't
    >> any there already),

    Marius> Is that so?  The 'backwards' option should only matter during display
    Marius> and we already have that code, right?

We do, but as we develop debugging tools further, I'd prefer not to
have the call everywhere that converts the frame number as typed by
the user to the correct stack index.  It's so easy to leave this call
out somewhere, and easy not to notice the omission.

As a further point, is similarity with GDB worth anything here?  GDB
numbers frames so that frame 0 is the innermost, so perhaps Guile
should do that too.  (GDB's direction also has the advantage that "up"
for frames coincides with "up" for frame numbers.)

        Neil



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

Re: Ditching (debug-enable 'backwards) ?

[Marius Vollmer]

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

> To be more precise, what I don't like about 'backwards is that it
> changes how the displayed frames are _numbered_:

Well, that sounds like the wrong thing to do wrong.  I thought that
'backwards would just print the same lines as the forward display,
only in reverse order.  There shouldn't really be any more difference
between the two, no?

> I have no objection to frames appearing in reverse order, but I prefer
> that they were then _numbered_ like this (artist's impression):

Yes, exactly my opinion as well.

>     Marius> Is that so?  The 'backwards' option should only matter
>     Marius> during display and we already have that code, right?
> 
> We do, but as we develop debugging tools further, I'd prefer not to
> have the call everywhere that converts the frame number as typed by
> the user to the correct stack index.  It's so easy to leave this call
> out somewhere, and easy not to notice the omission.

Yes.  We should either fix the backwards display then, or disable it
(but leave the code in so that it can be fixed later).

> As a further point, is similarity with GDB worth anything here?  GDB
> numbers frames so that frame 0 is the innermost, so perhaps Guile
> should do that too.  (GDB's direction also has the advantage that "up"
> for frames coincides with "up" for frame numbers.)

GDB's convention sounds more useful to me.  The innermost frame is
more important than the outermost one and should get a simple index.
With our convention, you have to know how many frames there are before
being able to name the innermost one or any frame relative to it.

Is it possible to fix this without creating a lot of confusion?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: Ditching (debug-enable 'backwards) ?

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    >> I have no objection to frames appearing in reverse order, but I prefer
    >> that they were then _numbered_ like this (artist's impression):

    Marius> Yes, exactly my opinion as well.

OK - thanks.

    Marius> GDB's convention sounds more useful to me.  The innermost frame is
    Marius> more important than the outermost one and should get a simple index.
    Marius> With our convention, you have to know how many frames there are before
    Marius> being able to name the innermost one or any frame relative to it.

    Marius> Is it possible to fix this without creating a lot of confusion?

I'll take a look.  I don't think it's acceptable to reverse the
meaning of `stack-ref', but it should be OK to change details of the
debugger display; if the Emacs interface relies on these details, we
can change it correspondingly.

        Neil



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

Re: Ditching (debug-enable 'backwards) ?

[Mikael Djurfeldt]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> GDB's convention sounds more useful to me.  The innermost frame is
> more important than the outermost one and should get a simple index.
> With our convention, you have to know how many frames there are before
> being able to name the innermost one or any frame relative to it.

But see my reply to Neil.

Best,
M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Ditching (debug-enable 'backwards) ?

[Mikael Djurfeldt]

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

> I have no objection to frames appearing in reverse order, but I prefer
> that they were then _numbered_ like this (artist's impression):
> 
> Backtrace:
> In unknown file:
>    ?: 2* [+ 1 "e"]
>    ?: 1  [/ 2 ...
>    ?: 0* (let ((x 1) (y "e")) (/ 2 (+ x y)))
> 
> (As a side point, note that indentation is not as informative when
> displaying frames backwards.)
> 
>     >> is likely to introduce bugs in the debugger code (if there aren't
>     >> any there already),
> 
>     Marius> Is that so?  The 'backwards' option should only matter during display
>     Marius> and we already have that code, right?
> 
> We do, but as we develop debugging tools further, I'd prefer not to
> have the call everywhere that converts the frame number as typed by
> the user to the correct stack index.  It's so easy to leave this call
> out somewhere, and easy not to notice the omission.
> 
> As a further point, is similarity with GDB worth anything here?  GDB
> numbers frames so that frame 0 is the innermost, so perhaps Guile
> should do that too.  (GDB's direction also has the advantage that "up"
> for frames coincides with "up" for frame numbers.)

Historic note + personal commentary:

I wrote the debugging evaluator and the backtracing code (yes, the
code sucks) during a hectic few days in 1995 as a part of a teaching
environment at KTH, it was important that the backtraces were both
informative and intuitive.  To me that meant that the direction of
time was downwards on the page and "up" in numbers.  As you point out,
"downwards on page" also means that indentation can be used in a
natural way to indicate evaluation of arguments.

If I remember it correctly what happened was: RMS wanted Guile
backtraces to look like GDB backtraces.  We argued quite a lot about
this and he finally allowed me to implement the current backtrace look
if I provided GDB backtraces as an option.

Personally, I've always been frustrated both with the order of frames
and the frame numbering in GDB, because 1. the most important frames
are far away from next command line so that your eyes have to jump
around on the page, 2. the most important frames disappear first
during scrolling, 3. I need to know how many frames are on the stack
in order to *compute* the frame number for the tenth (in time) frame
on the stack, and 4. that frame number *varies* depending on how far
you've run your program after that invocation.

In contrast, with the current default numbering style in Guile, you
never need to know the number of frames on the stack, since the
numbers are clearly written in front of the frame in the backtrace
listing.  In fact, they give you a feeling for how large the stack
is.

Mikael D.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel