removing bushdb related code in gud.el

removing bushdb related code in gud.el

[Masatake YAMATO]

Hi,

We(Rocky, the author of bashdb and I, a contributor) would like to 
remove bashdb related code in gud.el.

Bashdb has been improved/changed its output. 
As the result we have to update bashdb related code in gud.el; the
version of bashdb and bashdb related code in gud.el must be
synced. This is not problem during emacs development stage. 
I'm quite happy to work on such task.

However, once new version of emacs is released. The code
synchronization task is out of my hand; even if I update the code in
Savannah's repository, users may use released version of emacs and
gud.el bundled to it. 

To avoid users' confusion, we'd like to move bashdb related code(bashdb.el)
 in gud.el to bashdb itself. So we can provide well updated bashdb.el in
bashdb release.

Any objection?

Masatake YAMATO

--- gud.el	23  2月 2007 03:33:41 +0900	1.122
+++ gud.el	23  2月 2007 03:37:59 +0900	
@@ -58,7 +58,7 @@
 
 (defgroup gud nil
   "Grand Unified Debugger mode for gdb and other debuggers under Emacs.
-Supported debuggers include gdb, sdb, dbx, xdb, perldb, pdb (Python), jdb, and bash."
+Supported debuggers include gdb, sdb, dbx, xdb, perldb, pdb (Python), and jdb."
   :group 'unix
   :group 'tools)
 
@@ -166,18 +166,18 @@
     ([tbreak]	menu-item "Temporary Breakpoint" gud-tbreak
                   :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				'(gdbmi gdba gdb sdb xdb bashdb)))
+				'(gdbmi gdba gdb sdb xdb)))
     ([break]	menu-item "Set Breakpoint" gud-break
                   :enable (not gud-running)
 		  :visible (gud-tool-bar-item-visible-no-fringe))
     ([up]	menu-item "Up Stack" gud-up
 		  :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				 '(gdbmi gdba gdb dbx xdb jdb pdb bashdb)))
+				 '(gdbmi gdba gdb dbx xdb jdb pdb)))
     ([down]	menu-item "Down Stack" gud-down
 		  :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				 '(gdbmi gdba gdb dbx xdb jdb pdb bashdb)))
+				 '(gdbmi gdba gdb dbx xdb jdb pdb)))
     ([pp]	menu-item "Print S-expression" gud-pp
                   :enable (and (not gud-running)
 				  gdb-active-process)
@@ -196,7 +196,7 @@
     ([finish]	menu-item "Finish Function" gud-finish
                   :enable (not gud-running)
 		  :visible (memq gud-minor-mode
-				 '(gdbmi gdba gdb xdb jdb pdb bashdb)))
+				 '(gdbmi gdba gdb xdb jdb pdb)))
     ([stepi]	menu-item "Step Instruction" gud-stepi
                   :enable (not gud-running)
 		  :visible (memq gud-minor-mode '(gdbmi gdba gdb dbx)))
@@ -2286,127 +2286,6 @@
 		 (gud-jdb-build-source-files-list gud-jdb-directories
 						  "\\.java$"))))
     (fset 'gud-jdb-find-source 'gud-jdb-find-source-file)))
-\f
-
-;; ======================================================================
-;;
-;; BASHDB support. See http://bashdb.sourceforge.net
-;;
-;; AUTHOR:	Rocky Bernstein <rocky@panix.com>
-;;
-;; CREATED:	Sun Nov 10 10:46:38 2002 Rocky Bernstein.
-;;
-;; INVOCATION NOTES:
-;;
-;; You invoke bashdb-mode with:
-;;
-;;    M-x bashdb <enter>
-;;
-;; It responds with:
-;;
-;;    Run bashdb (like this): bash
-;;
-
-;; History of argument lists passed to bashdb.
-(defvar gud-bashdb-history nil)
-
-;; Convert a command line as would be typed normally to run a script
-;; into one that invokes an Emacs-enabled debugging session.
-;; "--debugger" in inserted as the first switch.
-
-;; There's no guarantee that Emacs will hand the filter the entire
-;; marker at once; it could be broken up across several strings.  We
-;; might even receive a big chunk with several markers in it.  If we
-;; receive a chunk of text which looks like it might contain the
-;; beginning of a marker, we save it here between calls to the
-;; filter.
-(defun gud-bashdb-marker-filter (string)
-  (setq gud-marker-acc (concat gud-marker-acc string))
-  (let ((output ""))
-
-    ;; Process all the complete markers in this chunk.
-    ;; Format of line looks like this:
-    ;;   (/etc/init.d/ntp.init:16):
-    ;; but we also allow DOS drive letters
-    ;;   (d:/etc/init.d/ntp.init:16):
-    (while (string-match "\\(^\\|\n\\)(\\(\\([a-zA-Z]:\\)?[^:\n]*\\):\\([0-9]*\\)):.*\n"
-			 gud-marker-acc)
-      (setq
-
-       ;; Extract the frame position from the marker.
-       gud-last-frame
-       (cons (match-string 2 gud-marker-acc)
-	     (string-to-number (match-string 4 gud-marker-acc)))
-
-       ;; Append any text before the marker to the output we're going
-       ;; to return - we don't include the marker in this text.
-       output (concat output
-		      (substring gud-marker-acc 0 (match-beginning 0)))
-
-       ;; Set the accumulator to the remaining text.
-       gud-marker-acc (substring gud-marker-acc (match-end 0))))
-
-    ;; Does the remaining text look like it might end with the
-    ;; beginning of another marker?  If it does, then keep it in
-    ;; gud-marker-acc until we receive the rest of it.  Since we
-    ;; know the full marker regexp above failed, it's pretty simple to
-    ;; test for marker starts.
-    (if (string-match "\032.*\\'" gud-marker-acc)
-	(progn
-	  ;; Everything before the potential marker start can be output.
-	  (setq output (concat output (substring gud-marker-acc
-						 0 (match-beginning 0))))
-
-	  ;; Everything after, we save, to combine with later input.
-	  (setq gud-marker-acc
-		(substring gud-marker-acc (match-beginning 0))))
-
-      (setq output (concat output gud-marker-acc)
-	    gud-marker-acc ""))
-
-    output))
-
-(defcustom gud-bashdb-command-name "bash --debugger"
-  "File name for executing bash debugger."
-  :type 'string
-  :group 'gud)
-
-;;;###autoload
-(defun bashdb (command-line)
-  "Run bashdb on program FILE in buffer *gud-FILE*.
-The directory containing FILE becomes the initial working directory
-and source-file directory for your debugger."
-  (interactive
-   (list (read-from-minibuffer "Run bashdb (like this): "
-			       (if (consp gud-bashdb-history)
-				   (car gud-bashdb-history)
-				 (concat gud-bashdb-command-name
-					 " "))
-			       gud-minibuffer-local-map nil
-			       '(gud-bashdb-history . 1))))
-
-  (gud-common-init command-line nil 'gud-bashdb-marker-filter)
-
-  (set (make-local-variable 'gud-minor-mode) 'bashdb)
-
-  (gud-def gud-break  "break %l"   "\C-b" "Set breakpoint at current line.")
-  (gud-def gud-tbreak "tbreak %l"  "\C-t" "Set temporary breakpoint at current line.")
-  (gud-def gud-remove "clear %l"   "\C-d" "Remove breakpoint at current line")
-  (gud-def gud-step   "step"       "\C-s" "Step one source line with display.")
-  (gud-def gud-next   "next"       "\C-n" "Step one line (skip functions).")
-  (gud-def gud-cont   "continue"   "\C-r" "Continue with display.")
-  (gud-def gud-finish "finish"     "\C-f" "Finish executing current function.")
-  (gud-def gud-up     "up %p"      "<" "Up N stack frames (numeric arg).")
-  (gud-def gud-down   "down %p"    ">" "Down N stack frames (numeric arg).")
-  (gud-def gud-print  "x %e"      "\C-p" "Evaluate BASH expression at point.")
-
-  ;; Is this right?
-  (gud-def gud-statement "eval %e" "\C-e" "Execute BASH statement at point.")
-
-  (setq comint-prompt-regexp "^bashdb<+(*[0-9]+)*>+ ")
-  (setq paragraph-start comint-prompt-regexp)
-  (run-hooks 'bashdb-mode-hook)
-  )
 
 ;;
 ;; End of debugger-specific information

Re: removing bushdb related code in gud.el

[Nick Roberts]

 > We(Rocky, the author of bashdb and I, a contributor) would like to 
 > remove bashdb related code in gud.el.

You would need to remove references in the manual too.

 > Bashdb has been improved/changed its output. 
 > As the result we have to update bashdb related code in gud.el; the
 > version of bashdb and bashdb related code in gud.el must be
 > synced. This is not problem during emacs development stage. 
 > I'm quite happy to work on such task.
 > 
 > However, once new version of emacs is released. The code
 > synchronization task is out of my hand; even if I update the code in
 > Savannah's repository, users may use released version of emacs and
 > gud.el bundled to it. 
 > 
 > To avoid users' confusion, we'd like to move bashdb related code(bashdb.el)
 >  in gud.el to bashdb itself. So we can provide well updated bashdb.el in
 > bashdb release.
 >
 > Any objection?

I guess if bashdb.el is always distributed with bash, and users know how to
put it in their load-path, then this makes sense.  New releases of Emacs might
break functionality but they will surely be less frequent than releases of
Bash.

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

Re: removing bushdb related code in gud.el

[Rocky Bernstein]

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

On 2/25/07, Nick Roberts <nickrob@snap.net.nz> wrote:
>
> > We(Rocky, the author of bashdb and I, a contributor) would like to
> > remove bashdb related code in gud.el.
>
> You would need to remove references in the manual too.


Yes, I guess so. It would be nice though  to mention that support for the
debugger can be found elsewhere.

> Bashdb has been improved/changed its output.
> > As the result we have to update bashdb related code in gud.el; the
> > version of bashdb and bashdb related code in gud.el must be
> > synced. This is not problem during emacs development stage.
> > I'm quite happy to work on such task.
> >
> > However, once new version of emacs is released. The code
> > synchronization task is out of my hand; even if I update the code in
> > Savannah's repository, users may use released version of emacs and
> > gud.el bundled to it.
> >
> > To avoid users' confusion, we'd like to move bashdb related code(
> bashdb.el)
> >  in gud.el to bashdb itself. So we can provide well updated bashdb.el in
> > bashdb release.
> >
> > Any objection?
>
> I guess if bashdb.el is always distributed with bash,



It is -- but that's a separate problem which we are also working on.  I
think you meant to say if "bashdb.el is always distributed with bashdb ".


and users know how to
> put it in their load-path, then this makes sense.


Debian based-distributions  already seem to have a convention and mechanism
for making sure it is in the load path (I think).

 New releases of Emacs might
> break functionality but they will surely be less frequent than releases of
> Bash.


Yes, when bashdb.el is distributed outside of GNU Emacs, it means that it
must cope with multiple versions and variants of Emacs. We've discussed this
previously, and we feel that it still the better this way. Working for us
here is the fact that there is a longer time between GNU Emacs releases than
bashdb releases.

By the way, in bashdb.el we've started adding testing via elk-test.el. What
is there is not very extensive , but at least it's a start.  If someone is
interested in extending to more of what's in gud.el, by all means take a
look at the code in the bashdb sources.

Thanks.

[-- Attachment #1.2: Type: text/html, Size: 3252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: removing bushdb related code in gud.el

[Richard Stallman]

    To avoid users' confusion, we'd like to move bashdb related code(bashdb.el)
     in gud.el to bashdb itself. So we can provide well updated bashdb.el in
    bashdb release.

Wouldn't it be better to have a protocol version number?
Then Emacs could still have the code, but if you change the protocol,
you would update the protocol version number.  Then the code in Emacs
would say "you need to install bashdb.el from <wherever>.

Re: removing bushdb related code in gud.el

[Rocky Bernstein]

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

You are correct that a protocol number has advantages in that it  guarantees
folks get a minimum version of GNU Emacs bashdb support. However given other
circumstances,  the real here benefit to everyone is negligible.

bashdb is not distributed as part of bash right now and in order to do any
sort of debugging you  need bashdb installed. So it's possible (in fact
likely) that folks will install GNU Emacs but not have this add-on and
things are broken. In theory the GNU Emacs gud code could check for the
presence of bashdb, but it doesn't yet (and it might be cumbersome to
write).

Furthermore, the issues we've been seeing aren't so much that the underlying
protocol changes (so things break), as much as where bugs  tend to get
reported, the speed of fixes, and frequency of user-visible releases of
minor improvements and enhancements. For example, the last change involved
changing a regular expression to accommodate Microsoft Windows. As part of
that fix, we added a little regression test for that case. I believe this
fix is part of the last release.

It is not clear that had the bug finder reported this to via the GNU Emacs
channels, the change would have be visible  to users as soon, or that there
would have been a regression test added. bashdb has and advantage or
disadvantage of being much smaller than GNU Emacs. Therefore we are able to
be more agile.

Finally, I think the argument is also equally valid the other way around
too. If gud had a protocol number,  it would help bashdb.el and other
add-ons, like the debugger for GNU Make for which there is a corresponding
GNU Emacs interface. That GNU Emacs lisp code  would check against  a
protocol number instead of GNU Emacs major/minor version numbers and adjust
accordingly.


On 2/25/07, Richard Stallman <rms@gnu.org> wrote:
>
>     To avoid users' confusion, we'd like to move bashdb related code(
> bashdb.el)
>      in gud.el to bashdb itself. So we can provide well updated bashdb.elin
>     bashdb release.
>
> Wouldn't it be better to have a protocol version number?
> Then Emacs could still have the code, but if you change the protocol,
> you would update the protocol version number.  Then the code in Emacs
> would say "you need to install bashdb.el from <wherever>.
>

[-- Attachment #1.2: Type: text/html, Size: 2723 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [Bashdb-devel] removing bushdb related code in gud.el

[Masatake YAMATO]

>     To avoid users' confusion, we'd like to move bashdb related code(bashdb.el)
>      in gud.el to bashdb itself. So we can provide well updated bashdb.el in
>     bashdb release.
> 
> Wouldn't it be better to have a protocol version number?
> Then Emacs could still have the code, but if you change the protocol,
> you would update the protocol version number.  Then the code in Emacs
> would say "you need to install bashdb.el from <wherever>.

Either bundling bashdb related code to gud.el or not,
generally introducing the protocol version number is good idea.

This point is that we should not add new code for enhancement till
releasing new version.

Masatake YAMATO

Re: removing bushdb related code in gud.el

[Richard Stallman]

I think I understand the situation now.  Since bashdb support
was not included in Emacs 21, I think it is ok to remove it now.

But first I want to see if anyone argues against it.

Re: removing bushdb related code in gud.el

[Nick Roberts]

 > I think I understand the situation now.  Since bashdb support
 > was not included in Emacs 21, I think it is ok to remove it now.
 > 
 > But first I want to see if anyone argues against it.

In the four or so years I've worked on gud.el, I can't remember anyone asking
about bashdb (except to remove it).  Also as they must have perogative over
their own software, I've removed it from gud.el (and documentation).

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

Re: [Bashdb-devel] removing bushdb related code in gud.el

[Masatake YAMATO]

>  > I think I understand the situation now.  Since bashdb support
>  > was not included in Emacs 21, I think it is ok to remove it now.
>  > 
>  > But first I want to see if anyone argues against it.
> 
> In the four or so years I've worked on gud.el, I can't remember anyone asking
> about bashdb (except to remove it).  Also as they must have perogative over
> their own software, I've removed it from gud.el (and documentation).

Thank you for working on this.

Masatake YAMATO