realgud now in elpa

realgud now in elpa

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

Folks -

With the last of the copyright assignments changed, a possible replacement
for "gud.el" called "realgud.el" is now in elpa.

I make lots of mistakes (which is why I work on debuggers), so no doubt
there will need to be some adjustment. Feel free to dig in or let me know.

Thanks.

[-- Attachment #2: Type: text/html, Size: 408 bytes --]

Re: realgud now in elpa

[Stefan Monnier]

> With the last of the copyright assignments changed, a possible replacement
> for "gud.el" called "realgud.el" is now in elpa.

Yay!

> I make lots of mistakes (which is why I work on debuggers), so no doubt
> there will need to be some adjustment. Feel free to dig in or let me know.

I'll be sure to complain loudly,


        Stefan

Re: realgud now in elpa

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 577 bytes --]

On 2016-07-30 10:56, Rocky Bernstein wrote:
> With the last of the copyright assignments changed, a possible replacement for "gud.el" called "realgud.el" is now in elpa. 

Wonderful! RealGUD really blew my mind when I first tried it. It's a wonderful piece of software — highly recommended.

Plus, Rocky is a great maintainer. All my pull requests and patches were promptly discussed and integrated when I started contributing; so much so that I'm now giving him a hand with maintaining myself :) And we'll be happy to get suggestions and help!

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: realgud now in elpa

[raman]

could the info documentation be part of the melpa distrib? 
-- 

Re: realgud now in elpa

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > could the info documentation be part of the melpa distrib? 

Info documentation for what?  And why melpa?
In general, the documention should go with the software it is about.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: realgud now in elpa

[T.V Raman]

s/melpa/elpa/  and for the record, most packages installed via the
package manager be it elpa or melpa come with almost no documentation.

Richard Stallman writes:
 > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
 > [[[ whether defending the US Constitution against all enemies,     ]]]
 > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
 > 
 >   > could the info documentation be part of the melpa distrib? 
 > 
 > Info documentation for what?  And why melpa?
 > In general, the documention should go with the software it is about.
 > 
 > -- 
 > Dr Richard Stallman
 > President, Free Software Foundation (gnu.org, fsf.org)
 > Internet Hall-of-Famer (internethalloffame.org)
 > Skype: No way! See stallman.org/skype.html.

-- 

-- 

Re: realgud now in elpa

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > s/melpa/elpa/  and for the record, most packages installed via the
  > package manager be it elpa or melpa come with almost no documentation.

It is important to write documentation for them.  How about asking
the authors of some packages to write manuals for them?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: realgud now in elpa

[raman]

Richard Stallman <rms@gnu.org> writes:

Which was the point behind my original note.

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > s/melpa/elpa/  and for the record, most packages installed via the
>   > package manager be it elpa or melpa come with almost no documentation.
>
> It is important to write documentation for them.  How about asking
> the authors of some packages to write manuals for them?

-- 

Re: realgud now in elpa

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would you like to write to the authors of a few chosen packages
(you choose them, if you're doing this) to ask them to write
manuals?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: realgud now in elpa

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 206 bytes --]

> Would you like to write to the authors of a few chosen packages
> (you choose them, if you're doing this) to ask them to write
> manuals?

Even better: write the manuals yourself, and send them :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: realgud now in elpa

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Would you like to write to the authors of a few chosen packages
  > > (you choose them, if you're doing this) to ask them to write
  > > manuals?

  > Even better: write the manuals yourself, and send them :)

If you are an expert user of the package, you might be able to do a
good job of that.  However, for a person who has never used it, that
is almost impossible.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: realgud now in elpa

[Michael Albinus]

Rocky Bernstein <rocky@gnu.org> writes:

> Folks - 

Hi Rocky,

> I make lots of mistakes (which is why I work on debuggers), so no
> doubt there will need to be some adjustment. Feel free to dig in or
> let me know.

make[1]: Entering directory '/usr/local/src/elpa'
Byte compiling packages/realgud/realgud.el
Unable to activate package ‘realgud’.
Required package ‘list-utils-0.4.2’ is unavailable
GNUmakefile:160: recipe for target 'packages/realgud/realgud.elc' failed
make[1]: *** [packages/realgud/realgud.elc] Error 255

> Thanks.

Best regards, Michael.

Re: realgud now in elpa

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

In the recently-release realgud, I'm not seeing subdirectories showing up
in elpa.

  -rw-r--r--  1 root root  986 Jul 31 13:01 realgud-autoloads.el
  -rw-r--r--  1 root root 8019 Jul 31 13:01 realgud.el
  -rw-r--r--  1 root root  249 Jul 31 13:01 realgud-pkg.el

Although it is in git. What controls this?

Thanks.


On Sat, Jul 30, 2016 at 10:56 AM, Rocky Bernstein <rocky@gnu.org> wrote:

> Folks -
>
> With the last of the copyright assignments changed, a possible replacement
> for "gud.el" called "realgud.el" is now in elpa.
>
> I make lots of mistakes (which is why I work on debuggers), so no doubt
> there will need to be some adjustment. Feel free to dig in or let me know.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1571 bytes --]

Re: realgud now in elpa

[joakim]

Rocky Bernstein <rocky@gnu.org> writes:

> In the recently-release realgud, I'm not seeing subdirectories showing up in elpa.
>
> -rw-r--r-- 1 root root 986 Jul 31 13:01 realgud-autoloads.el
> -rw-r--r-- 1 root root 8019 Jul 31 13:01 realgud.el
> -rw-r--r-- 1 root root 249 Jul 31 13:01 realgud-pkg.el
>
> Although it is in git. What controls this? 

Do you mean that you would like to add an empty subdirectory, that
should be git managed?

If so, you need to have a dummy file in the subdirectory.

See for instance:
http://stackoverflow.com/questions/115983/how-can-i-add-an-empty-directory-to-a-git-repository

>
> Thanks.
>
> On Sat, Jul 30, 2016 at 10:56 AM, Rocky Bernstein <rocky@gnu.org> wrote:
>
>  Folks - 
>
>  With the last of the copyright assignments changed, a possible replacement for "gud.el" called "realgud.el" is now in elpa. 
>
>  I make lots of mistakes (which is why I work on debuggers), so no doubt there will need to be some adjustment. Feel free to dig in or let me know.
>
>  Thanks.
>
>

-- 
Joakim Verona

Re: realgud now in elpa

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

No, I don't mean empty subdirectories but ones that have files in them.
Compare the above with or what you see installing from elpa with:
http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages/realgud

On Sun, Jul 31, 2016 at 2:16 PM, <joakim@verona.se> wrote:

> Rocky Bernstein <rocky@gnu.org> writes:
>
> > In the recently-release realgud, I'm not seeing subdirectories showing
> up in elpa.
> >
> > -rw-r--r-- 1 root root 986 Jul 31 13:01 realgud-autoloads.el
> > -rw-r--r-- 1 root root 8019 Jul 31 13:01 realgud.el
> > -rw-r--r-- 1 root root 249 Jul 31 13:01 realgud-pkg.el
> >
> > Although it is in git. What controls this?
>
> Do you mean that you would like to add an empty subdirectory, that
> should be git managed?
>
> If so, you need to have a dummy file in the subdirectory.
>
> See for instance:
>
> http://stackoverflow.com/questions/115983/how-can-i-add-an-empty-directory-to-a-git-repository
>
> >
> > Thanks.
> >
> > On Sat, Jul 30, 2016 at 10:56 AM, Rocky Bernstein <rocky@gnu.org> wrote:
> >
> >  Folks -
> >
> >  With the last of the copyright assignments changed, a possible
> replacement for "gud.el" called "realgud.el" is now in elpa.
> >
> >  I make lots of mistakes (which is why I work on debuggers), so no doubt
> there will need to be some adjustment. Feel free to dig in or let me know.
> >
> >  Thanks.
> >
> >
>
> --
> Joakim Verona
>

[-- Attachment #2: Type: text/html, Size: 2382 bytes --]

Re: realgud now in elpa

[Stefan Monnier]

> No, I don't mean empty subdirectories but ones that have files in them.
> Compare the above with or what you see installing from elpa with:
> http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages/realgud

To decide whether a package is "simple" or "multi", the script simply
looks at the number of .el files (and ELPA generally doesn't provide
much support for .el files in sub-directories, so the script only looks
at the number of .el files in the top-level dir).

IOW you need to add

    Package-Type: multi

to realgud.el (and bump the release number).


        Stefan

Re: realgud now in elpa

[Eli Zaretskii]

> From: Rocky Bernstein <rocky@gnu.org>
> Date: Sat, 30 Jul 2016 10:56:33 -0400
> Cc: clement.pitclaudel@live.com
> 
> Folks - 
> 
> With the last of the copyright assignments changed, a possible replacement for "gud.el" called "realgud.el" is
> now in elpa. 
> 
> I make lots of mistakes (which is why I work on debuggers), so no doubt there will need to be some
> adjustment. Feel free to dig in or let me know.

Thanks.  It's good to see that the debugger front-end gets worked on
again, after a long pause.

I've played with the package, and the below are my comments.  I hope
you will not take it as any discouragement of your efforts; rather the
opposite: we the maintainers value anyone who is willing to step up
and contribute real work.  Please accept these as ways to further
improve your package, so it achieves the maximum benefit for our
users.

Here are the comments:

1. The package needs additional dependencies to start working:

   load-relative
   loc-changes
   list-utils

2. "M-x realgud:gdb RET" fails to propose emacs.exe (or any other
   executable file) as the file to debug, after a longish delay
   (probably used for looking up files in the current directory).
   When I type "./emacs.exe RET", it says:

     emacs.exe is large (66.6M), really open? (y or n)

   This prompt was unexpected, since Emacs doesn't need to visit the
   executable.

   Answering "y" causes another unexpected message in the echo area:

    Debugger track mode is already enabled.

   Why "already"?  And why is it important for me to know that mode is
   already active?  (The message sounds as if I made some mistake.)

3. The UI is the old GUD style, without the additional windows
   available with gdb-mi.el, and features available in those windows.

   I think a modern debugger UI should be similar to what other IDEs
   offer, and gdb-mi is much closer to that ideal than either GUD or
   realgud.

4. The GDB interface used is annotations, which is deprecated by the
   GDB developers, not the more modern MI.  Moreover, the annotations
   emitted by GDB are actually shown in the command buffer.  Example:

   Temporary breakpoint 3, main (argc=2, argv=0xa412f8) at emacs.c:674
   ^Z^Zd:\foo\bar\src\emacs.c:674:19557:beg:0x11517b0
   (gdb) n
   ^Z^Zd:\foo\bar\src\emacs.c:675:19578:beg:0x11517b7
   (gdb)

   I don't think seeing these annotations is useful; gud.el doesn't
   show them.

5. Completion seems to always complete on file names, even when typing
   parts of GDB commands that have nothing to do with file names.
   E.g., typing TAB at (gdb) prompt mostly says "No match", but if you
   type "sea TAB", it will complete to search.c (when the default
   directory is the Emacs src directory).  My guess is that the
   completion is either not delegated to GDB, but instead attempted by
   the package itself, or the completion provided by GDB is used
   incorrectly.  Because GDB has no problems with completing each
   command correctly.

6. The support for displaying values of variables in tooltips requires
   a click; the original GUD didn't, which IMO was more convenient.

7. Clicking on the fringe sets a breakpoint and displays that fact on
   the fringe; a second click deletes the breakpoint, but the fringe
   marker is not removed.  Additional clicks on that marker cause a
   "delete N" command to be again sent to GDB, which responds with an
   error message.

8. Clicking the "Next" button on the tool bar leaves a fading trace of
   the previous stop points (arrow1, arrow2, etc.), which is nice.
   However, the same trace is displayed in the command buffer, where I
   think it's unnecessary and confusing.  In fact, for the arrow to be
   shown in the command buffer is something I don't expect.  On a TTY
   frame, showing these arrows in the command buffer overwrites the
   GDB prompts and other information in the 1st 2 columns of each line
   where an arrow is displayed.

9. I hoped this will support debugging ELisp programs, but it doesn't,
   which I think is unfortunate.  One other omission I spotted is the
   GNU Awk's built-in debugger.

10.An attempt to get a backtrace hangs Emacs; C-g gets out of the
   hang, but doesn't display anything.

Thanks again for working on this.

Re: realgud now in elpa

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 9180 bytes --]

Thanks for trying out the package and your detailed comments. As you
probably know as an emacs maintainer, feedback and bug reporting is very
helpful.

Although I'll make some general comments here and some more specific ones
below inline, bug reporting for ELPA packages isn't something that
generally goes on in emacs-devel. Issue tracking for this package is
currently done in  https://github.com/realgud/realgud/issues . If you look
there, some of the concerns you raise, have already been reported.

I'm sure  I don't have to tell you as an emacs maintainer the value of
separating out bugs into individual reports so that they can be tracked
separately. So I invite you to look at the list of issues and report those
that haven't been mentioned raised or add comments to the ones that have
where appropriate.

Other comments in line.

On Sun, Jul 31, 2016 at 2:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Rocky Bernstein <rocky@gnu.org>
> > Date: Sat, 30 Jul 2016 10:56:33 -0400
> > Cc: clement.pitclaudel@live.com
> >
> > Folks -
> >
> > With the last of the copyright assignments changed, a possible
> replacement for "gud.el" called "realgud.el" is
> > now in elpa.
> >
> > I make lots of mistakes (which is why I work on debuggers), so no doubt
> there will need to be some
> > adjustment. Feel free to dig in or let me know.
>
> Thanks.  It's good to see that the debugger front-end gets worked on
> again, after a long pause.
>
> I've played with the package, and the below are my comments.



It must have been from the git repo, since last I tried installing via
ELPA, as I reported, subdirectories were missing.

I hope
> you will not take it as any discouragement of your efforts; rather the
> opposite: we the maintainers value anyone who is willing to step up
> and contribute real work.  Please accept these as ways to further
> improve your package, so it achieves the maximum benefit for our
> users.
>

I don't take it as discouragement. But please use the issue tracker for
reasons mentioned above.


> Here are the comments:
>
> 1. The package needs additional dependencies to start working:
>
>    load-relative
>    loc-changes
>    list-utils
>

The dependency on list-utils has been dropped. You probably need to update
your elpa git repo if you are still seeing this. As for load-relative and
loc-changes, they do work. (load-relative has problems inside of a
spacemacs installer, but I doubt that's what you are running into.)

So the above comment is too vague to be actionable. Please make it more
precise and add it as an issue in the github tracker.



> 2. "M-x realgud:gdb RET" fails to propose emacs.exe (or any other
>    executable file) as the file to debug,


It is possible that on Microsoft Windows environments it will fail to find
exe's. Suggest a patch. I'm not sure however that it is a bug not to
propose a file to debug since gdb can work by taking a process number
instead of a program name.

after a longish delay
>    (probably used for looking up files in the current directory).
>    When I type "./emacs.exe RET", it says:
>
>      emacs.exe is large (66.6M), really open? (y or n)
>
>    This prompt was unexpected, since Emacs doesn't need to visit the
>    executable.
>

File an issue on this.

>
>    Answering "y" causes another unexpected message in the echo area:
>
>     Debugger track mode is already enabled.
>
>    Why "already"?  And why is it important for me to know that mode is
>    already active?  (The message sounds as if I made some mistake.)
>

Probably one of the many bugs that needs to be track down.


>
> 3. The UI is the old GUD style, without the additional windows
>    available with gdb-mi.el, and features available in those windows.
>
>    I think a modern debugger UI should be similar to what other IDEs
>    offer, and gdb-mi is much closer to that ideal than either GUD or
>    realgud.
>


I've looked at gdb-mi and how it handles windows and it feels to me a bit
unmodular. But by all means if you understand how to extract that code,
please submit a pull request with the changes or whatever the corresponding
thing in savannah is.


>
> 4. The GDB interface used is annotations, which is deprecated by the
>    GDB developers, not the more modern MI.  Moreover, the annotations
>    emitted by GDB are actually shown in the command buffer.  Example:
>
>    Temporary breakpoint 3, main (argc=2, argv=0xa412f8) at emacs.c:674
>    ^Z^Zd:\foo\bar\src\emacs.c:674:19557:beg:0x11517b0
>    (gdb) n
>    ^Z^Zd:\foo\bar\src\emacs.c:675:19578:beg:0x11517b7
>    (gdb)
>
>    I don't think seeing these annotations is useful; gud.el doesn't
>    show them.
>

Integrating the MI interface into realgud may require some thought. As with
other things feel free to submit patches to move that code over,

In general, right now gdb support just isn't as good as gdb-mi. So if your
debugger needs are simply for gdb as it appears, then stick to gdb-mi.

And/or dig in and help improve gdb support.


> 5. Completion seems to always complete on file names, even when typing
>    parts of GDB commands that have nothing to do with file names.
>    E.g., typing TAB at (gdb) prompt mostly says "No match", but if you
>    type "sea TAB", it will complete to search.c (when the default
>    directory is the Emacs src directory).  My guess is that the
>    completion is either not delegated to GDB, but instead attempted by
>    the package itself, or the completion provided by GDB is used
>    incorrectly.  Because GDB has no problems with completing each
>    command correctly.


Probably a bug. Submit an issue.


>
> 6. The support for displaying values of variables in tooltips requires
>    a click; the original GUD didn't, which IMO was more convenient.
>


For gdb this makes sense. However in most cases it was disabled for a
reason. In other languages you are running eval and that can be state
changing,
So for other languages this will probably stay as is. Maybe there can be a
flag that says automatically run eval.

And given that, there is now the question of whether things should be
consistent in gdb with the way other things work. I'm kind of ambivalent.
If someone proposes a patch for realgud's gdb we'll probably try it the
other way.


> 7. Clicking on the fringe sets a breakpoint and displays that fact on
>    the fringe; a second click deletes the breakpoint, but the fringe
>    marker is not removed.  Additional clicks on that marker cause a
>    "delete N" command to be again sent to GDB, which responds with an
>    error message.
>

I think this bug has been reported,.


>
> 8. Clicking the "Next" button on the tool bar leaves a fading trace of
>    the previous stop points (arrow1, arrow2, etc.), which is nice.
>    However, the same trace is displayed in the command buffer, where I
>    think it's unnecessary and confusing.  In fact, for the arrow to be
>    shown in the command buffer is something I don't expect.  On a TTY
>    frame, showing these arrows in the command buffer overwrites the
>    GDB prompts and other information in the 1st 2 columns of each line
>    where an arrow is displayed.
>

Not sure that erasing part of a GDB prompt is that bad. Open an issue so
this could be discussed separately.

>
> 9. I hoped this will support debugging ELisp programs, but it doesn't,
>    which I think is unfortunate.  One other omission I spotted is the
>    GNU Awk's built-in debugger.
>

Ah - this is a common comment.

When rms wrote emacs he designed it with it being "extensible" and
"modular". In the description of realgud I in fact use the term "modular"
too and was very much thinking of rms's description of emacs. I'll also
probably add the word "extensible".

"Extensible" here I think meant not that rms was going to extend it in all
the ways that others were going to imagine. But that could be extended,
especially by others if they so choose, Since the program is modular, it is
straightforward to extend.

Although I was aware that there is a debugger for GNU Make
<https://github.com/rocky/remake>, I was *not *previously aware that there
was one for GNU awk. But that's okay, I just learned this and this is good
to know.
I took a look at it and it seems very straightforward to add. It probably
could be added in a couple of hours or so.

However, I'm not a big user of GNU awk and it is not something I will
probably be able to  undertake or support.

But as I said, this question though comes up a lot. And so I have written
instructions for how to add a new debugger
<https://github.com/realgud/realgud/wiki/How-to-add-a-new-debugger>. These
instructions are a little github centric, but I'm sure you will have no
trouble adapting them savannah's git.

Supporting debugging ELisp is something I would like to see happen and may
eventually do. But it is something that will probably require a bit of
thought.


> 10.An attempt to get a backtrace hangs Emacs; C-g gets out of the
>    hang, but doesn't display anything.


Another bug I think already reported for other debuggers, but not on gdb,
Is probably related to MS Windows interaction.


> Thanks again for working on this.
>

Thanks for your feedback.

[-- Attachment #2: Type: text/html, Size: 13867 bytes --]

Re: realgud now in elpa

[Eli Zaretskii]

> From: Rocky Bernstein <rocky@gnu.org>
> Date: Sun, 31 Jul 2016 19:58:11 -0400
> Cc: emacs-devel@gnu.org, clement.pitclaudel@live.com
> 
> Although I'll make some general comments here and some more specific ones below inline, bug reporting for
> ELPA packages isn't something that generally goes on in emacs-devel. Issue tracking for this package is
> currently done in https://github.com/realgud/realgud/issues . If you look there, some of the concerns you
> raise, have already been reported.

Actually, all of them have been reported.

Just one comment: there was a discussion there about fixing the
completion.  My suggestion is simply to use the completion provided by
GDB, because GDB always knows better how to complete various parts of
a command.  E.g., some parts may be file names, other programming
symbols, still others option values, etc.

Thanks.