gud.el organization and adding debuggers

gud.el organization and adding debuggers

[R. Bernstein]

Recently I've been working on debuggers for GNU make (mdb) and
extending the Python debugger (pydb). And of course I would like
these to be work well from inside GNU Emacs (via gud).

Well, it seems I went through this once before with the bash debugger:
The procedure if I recall correctly was that I cut-and-past a new
section of gud.el. The cut-and-past for a debugger portion seems to be
the first Emacs Lisp statement that starts: (defvar gud-xxx-history
nil) - and the comments before.

And then you submit a patch; perhaps it's accepted; and then wait
maybe 3 years for the next release to come out. :-)

Hmmm. In foundling projects like these debugger projects, releases
occur a bit quicker and I think it is important that they do. To get
the word out, probably one needs to submit some standalone Emacs Lisp
code with the package.

Not really a problem. You basically add a (require 'gud) and
cut and past the code that starts (devar gud-xxx-history ... 

Well, almost. There's this declaration of gud-menu-map towards the top
of gud.el and that lists capabilities for all of the debuggers it
knows about. In order to get capabilities for the menu items that gud
doesn't think your debugger will have (like "up") and disable features
that gud thinks your debugger *must* have (like "stepi"??), one needs
to do something additional. What I've been doing is including in the
function which runs the debugger (e.g. bashdb, mdb or pydb) a
define-key function like this:

  (define-key gud-menu-map [up]        '("Up Stack" . gud-up))

I'm not a GNU-Emacs wizard, so no doubt someone may or should correct
me if this is not the most linguistically pure Lisp thing to do. But
it does seem to set the menu correctly for those specific debugger
buffers while not interfering with other debugger buffers.

Now let's come back to gud.el and how it is organized. It would focus
the attention of those would-be cut-and-past debugger extenders like
myself if say all those debuggers were broken out into their own file
and possibly pulled in by require's (or something similar - again, I"m
not a wizard). Seems to be just a little cleaner and more modular. If
one needs to remove a debugger (e.g. someone forgot to submit GPL
papers), you remove the "require" and the associated file.

So in this scenario to add a new debugger you copy a *file* rather
than a section of this file and *forget* to modify that
gud-menu-map. And along with this, I guess I'm also suggesting that
instead of listing all of the debugger capabilities in the
easy-mmode-defmap gud-menu-map, the capabilities would be added in the
individual debuggers.

- - - -

Some other miscellaneous remarks. I note that in gud.el CVS more
gud-menu-map items have been added. Excellent! One of them is "run",
but I note that most of the time it is nil. I'm assuming "run" means
the gdb "run" command, which I think would better be called "restart".

If gud's "run" is supposed to indicate something else, then given it's
not used all that much even in gud, then I'd suggest renaming it to
mean "restart" or adding a "restart" menu item. bashdb for example has
such a command, so does gdb, perldb, mdb, and pydb. In other words,
restarting is a pretty common thing you might want to do.

The other menu items that I've added to my debuggers is 

* something to show a stack trace -- gud-where with key T which is
  what perldb, mdb, pydb and bashdb use.

* something to toggle line tracing

- - - 

"local-set-key [menu-bar debug up]" is used in the various
debuggers. On my GNU Emacs 21.4.1 (GNU/Linux) with X Windows, I am not
aware of any evidence of menu-bar in the display. Where is it?

Thanks.

Re: gud.el organization and adding debuggers

[Stefan Monnier]

> So in this scenario to add a new debugger you copy a *file* rather
> than a section of this file and *forget* to modify that
> gud-menu-map. And along with this, I guess I'm also suggesting that
> instead of listing all of the debugger capabilities in the
> easy-mmode-defmap gud-menu-map, the capabilities would be added in the
> individual debuggers.

Yes, GUD's support for particular debuggers should be made more modular.
It should also be possible to have several GUD sessions using different
debuggers at the same time.

Patches welcome.

I think a good first step would be to kill gud-def.
Instead of gud sub-modes using

  (gud-def gud-break "break %f:%l"  "\C-b" "Set breakpoint at current line.")

in their main function, we could have a top-level (for example)

  (define-gud-cmd gud-break "\C-b" "Set breakpoint at current line.")

and then the gud sub-mode would only do something like

  (set (make-local-variable 'gud-break-cmd) "break %f:%l")

so the global menu could use
  :visible gud-break-cmd
instead of
  :visible (memq gud-minor-mode '(gdbmi gdb dbx jdb))

Of course, maybe this is not the best idea.  I'm also thinking that some
each gud sub-mode should be defined as a major mode that derives from
gud-mode.


        Stefan

Re: gud.el organization and adding debuggers

[R. Bernstein]

Stefan Monnier writes:
 > Yes, GUD's support for particular debuggers should be made more modular.
 > It should also be possible to have several GUD sessions using different
 > debuggers at the same time.

Huh? Currently I have have no problem having several GUD sessions. And
if I want to debug the same program more than once simultaneously a
"rename-buffer" or "rename-uniquely" works for me.

 > Patches welcome.

You *did* read the part where I wrote: 
  I'm not a GNU-Emacs wizard, ... 
  again, I'm not a wizard).

However, if there seems to be a consensus on this, I'd be happy to
break gud.el into a generic file (gud.el) and several
debugger-specific files (bashdb.el, mdb.el, pydb.el, etc.). Also make
the changes I suggested in my previous email of using "define-key
gud-menu-map" and removing entries from "easy-mmode-defmap
gud-menu-map".

However when it gets to stuff like this: 

 > I think a good first step would be to kill gud-def.
 > Instead of gud sub-modes using
... 

you are out of my league. I don't really understand what you are
talking about. If you really think this is the way to go, you may be
the best candidate for doing it. ;-)

Re: gud.el organization and adding debuggers

[Stefan Monnier]

>> Yes, GUD's support for particular debuggers should be made more modular.
>> It should also be possible to have several GUD sessions using different
>> debuggers at the same time.

> Huh? Currently I have have no problem having several GUD sessions.

Really?  And those GUD sessions don't all use the same debugger?
Which debuggers do they use?

> And if I want to debug the same program more than once simultaneously
> a "rename-buffer" or "rename-uniquely" works for me.

The problem is (among a few others) that each sessions makes global changes.
E.g. `gud-def' redefines globally the text sent to the underlying debuggers.

> However, if there seems to be a consensus on this, I'd be happy to
> break gud.el into a generic file (gud.el) and several
> debugger-specific files (bashdb.el, mdb.el, pydb.el, etc.). Also make
> the changes I suggested in my previous email of using "define-key
> gud-menu-map" and removing entries from "easy-mmode-defmap
> gud-menu-map".

I'd rather keep as many entries in gud-menu-map as possible, and simply make
them invisible when the debugger doesn't support them.  This will ensure
better consistency between the various debuggers supported.


        Stefan

Re: gud.el organization and adding debuggers

[R. Bernstein]

Stefan Monnier writes:
 > >> Yes, GUD's support for particular debuggers should be made more modular.
 > >> It should also be possible to have several GUD sessions using different
 > >> debuggers at the same time.
 > 
 > > Huh? Currently I have have no problem having several GUD sessions.
 > 
 > Really?  And those GUD sessions don't all use the same debugger?
 > Which debuggers do they use?

Whatever I asked to be debugged. Could be perl's, mdb, bashdb, pydb
and/or gdb. As I look at my emacs buffer list, I see all of them in
use right now. The two gdb sessions debug different programs and have
different breakpoints set for each -- different gdb states (file args,
etc.), and that is true in other debuggers when I debug multiple
programs.

If you're trying to be diadactic, give it up. I wrote "Currently I
have no problem having serveral GUD sessions", and just take that at
face value. No doubt there are subtleties I'm missing and perhaps when
you add into GNU Emacs in whatever it is you are clearly conveying (to
others), feeble me will see the light and marvel at it.

I'm still down at the level where I am trying to understand where/when
the "local-set-key" of the "menu-bar" keymap makes itself evident to
users. ;-)

 > 
 > > And if I want to debug the same program more than once
 > > simultaneously a "rename-buffer" or "rename-uniquely" works for
 > > me.
 > 
 > The problem is (among a few others) that each sessions makes global changes.
 > E.g. `gud-def' redefines globally the text sent to the underlying debuggers.

Okay. 

 > I'd rather keep as many entries in gud-menu-map as possible, and simply make
 > them invisible when the debugger doesn't support them.  This will ensure
 > better consistency between the various debuggers supported.

By all means -- GO FOR IT! I'm assuming these changes you envision
will at least solve the set of issues that have been troubling me.

Thanks for volunteering to take this on.

Re: gud.el organization and adding debuggers

[Stefan Monnier]

>> >> Yes, GUD's support for particular debuggers should be made more modular.
>> >> It should also be possible to have several GUD sessions using different
>> >> debuggers at the same time.
>> 
>> > Huh? Currently I have have no problem having several GUD sessions.
>> 
>> Really?  And those GUD sessions don't all use the same debugger?
>> Which debuggers do they use?

> Whatever I asked to be debugged. Could be perl's, mdb, bashdb, pydb
> and/or gdb. As I look at my emacs buffer list, I see all of them in
> use right now.

Impressive.

> The two gdb sessions debug different programs and have

Two GDB sessions is fine, since it's twice the same debugger.

> If you're trying to be diadactic, give it up. I wrote "Currently I
> have no problem having serveral GUD sessions", and just take that at
> face value. No doubt there are subtleties I'm missing and perhaps when
> you add into GNU Emacs in whatever it is you are clearly conveying (to
> others), feeble me will see the light and marvel at it.

Well, in my little experince trying to use two different debuggers at the
same time, the problems were not subtle.  But it looks like it's not always
that bad.


        Stefan

gud.el organization and adding debuggers

[Nick Roberts]

 ...
 > In order to get capabilities for the menu items that gud
 > doesn't think your debugger will have (like "up") and disable features
 > that gud thinks your debugger *must* have (like "stepi"??), one needs
 > to do something additional.

gud-stepi is only enabled for gdb and dbx.  Why do you have to disable it?


 > So in this scenario to add a new debugger you copy a *file* rather
 > than a section of this file and *forget* to modify that
 > gud-menu-map. And along with this, I guess I'm also suggesting that
 > instead of listing all of the debugger capabilities in the
 > easy-mmode-defmap gud-menu-map, the capabilities would be added in the
 > individual debuggers.

As always, it might be a bit more complicated than you think.  For example,
there are currently 2 modes for GDB (3 if you include one distributed with
GDB).

 > Some other miscellaneous remarks. I note that in gud.el CVS more
 > gud-menu-map items have been added. Excellent! One of them is "run",
 > but I note that most of the time it is nil. I'm assuming "run" means
 > the gdb "run" command, which I think would better be called "restart".
 >
 > If gud's "run" is supposed to indicate something else, then given it's
 > not used all that much even in gud, 


I think you're confused.  nil just means there is no keybinding, not that
its not used.  It just appears on the menu bar and tool bar.

 >                                    then I'd suggest renaming it to
 > mean "restart" or adding a "restart" menu item. bashdb for example has
 > such a command, so does gdb, perldb, mdb, and pydb. In other words,
 > restarting is a pretty common thing you might want to do.

GDB's run command *is* the restart command.  You could rename gud-run
to gud-restart but I think that would be confusing (GDB is the principal
debugger for GUD).  What should I add for basdb?  The following?

  (gud-def gud-run    "restart"	     nil    "Start/restart the program.")

 > The other menu items that I've added to my debuggers is 
 > 
 > * something to show a stack trace -- gud-where with key T which is
 >   what perldb, mdb, pydb and bashdb use.

Do you mean in a separate buffer?  GDB does this now.  If you can do this
with other debuggers e.g bash that would be good but you need to be careful
about updating.

 > * something to toggle line tracing
 > 
 > - - - 
 > 
 > "local-set-key [menu-bar debug up]" is used in the various
 > debuggers. On my GNU Emacs 21.4.1 (GNU/Linux) with X Windows, I am not
 > aware of any evidence of menu-bar in the display. Where is it?

On GNU Emacs 21.4 gud-up should be visible with gdb, dbx, and xdb.  If you
can't even see the menu bar, what happens if you do menu-bar-mode?


Nick                                           http://www.inet.net.nz/~nickrob

Re: gud.el organization and adding debuggers

[Nick Roberts]

 > I think a good first step would be to kill gud-def.
 > Instead of gud sub-modes using
 > 
 >   (gud-def gud-break "break %f:%l"  "\C-b" "Set breakpoint at current line.")
 > 
 > in their main function, we could have a top-level (for example)
 > 
 >   (define-gud-cmd gud-break "\C-b" "Set breakpoint at current line.")
 > 
 > and then the gud sub-mode would only do something like
 > 
 >   (set (make-local-variable 'gud-break-cmd) "break %f:%l")
 > 
 > so the global menu could use
 >   :visible gud-break-cmd
 > instead of
 >   :visible (memq gud-minor-mode '(gdbmi gdb dbx jdb))

Yes.  Lets do it after the release.  Ha! ha!

Nick

Re: gud.el organization and adding debuggers

[R. Bernstein]

Nick Roberts in response to Stefan Monnier's remark:
 >  > I think a good first step would be to kill gud-def.
 >  > ...
 > Yes.  Lets do it after the release.  Ha! ha!

I have a proposal that isn't as drastic and helps at least in the
situations I've encountered. And I think it could be done in such a
way that there isn't any chance of negative impact.

Basically, I propose that the bash debugger code that was added for
this release now be put in a separate file, say bashdb.el, in the same
directory as gud.el. In other words the bashdb.el that is currently
getting distributed anyway would just be added as part of the Emacs
distribution.

Re: gud.el organization and adding debuggers

[Nick Roberts]

 > Basically, I propose that the bash debugger code that was added for
 > this release now be put in a separate file, say bashdb.el, in the same
 > directory as gud.el. In other words the bashdb.el that is currently
 > getting distributed anyway would just be added as part of the Emacs
 > distribution.

Without the types of change that Stefan is proposing I don't see that
there is much benefit.  Its quite easy to navigate to the relevant
debugger within gud.el and using separate files wouldn't stop the debuggers
from interfering with each other.

Nick