bashdb-devel — Developer's discussion mailing list

Re: [Bashdb-devel] make check fails (OS X)

[Rocky B. <roc...@gm...>]

I don't see  enough information on the failure to give anything but general
suggestions. The most obvious one is to pay attention to warnings and
messages that appear when you run "configure"  "make" and of course "make
test".

>From the output below I see that one of the test programs that failed is
called run-watch2. It should be located in a directory called "test". Run
that single program (run-watch2) from the directory it is located in. The
idea of that test program and others is to run a sequence of debuggers
commands and compare the output against known good output.

Good luck!

On 7/15/07, Louis Munro <lm...@lo...> wrote:
>
> Hello,
> My make check fails (23 out of 25 tests) when trying to build
> bashdb-3.1-0.08.
> I've succesfully installed it on debian stable but OS X (10.4) seems
> reluctant to allow me the bliss of debugging in emacs...
>
> A bit of background:
> - I have installed readline 5.2, bash 3.2 and emacs 22.1 from source in
> /usr/local/ (but I have started with $EMACS undefined to see if it would
> compile with the default emacs 21 in /usr/bin/emacs, changing $EMACS to
> /usr/local/bin/emacs doesn't seems to make any difference anyway, make
> check still fails).
>
> - Last 10 lines of make-check.log (2619 more available if needed):
> +Breakpoint 1 hit (1 times).
> +(dbg-test1.sh:17):
> +17:    fn3() {
> + 0 (echo "x is $x, ? is $?"): x is 29, ? is 0
> ++ quit
> FAIL: run-watch2
> ===================================================
> 23 of 25 tests failed
> Please report to bas...@li...
> ===================================================
>
> Any help much appreciated...
>
> Louis
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>
>
>

[Bashdb-devel] make check fails (OS X)

[Louis M. <lm...@lo...>]

Hello,
My make check fails (23 out of 25 tests) when trying to build
bashdb-3.1-0.08.
I've succesfully installed it on debian stable but OS X (10.4) seems
reluctant to allow me the bliss of debugging in emacs...

A bit of background:
- I have installed readline 5.2, bash 3.2 and emacs 22.1 from source in
/usr/local/ (but I have started with $EMACS undefined to see if it would
compile with the default emacs 21 in /usr/bin/emacs, changing $EMACS to
/usr/local/bin/emacs doesn't seems to make any difference anyway, make
check still fails).

- Last 10 lines of make-check.log (2619 more available if needed):
+Breakpoint 1 hit (1 times).
+(dbg-test1.sh:17):
+17:    fn3() {
+ 0 (echo "x is $x, ? is $?"): x is 29, ? is 0
++ quit
FAIL: run-watch2
===================================================
23 of 25 tests failed
Please report to bas...@li...
===================================================

Any help much appreciated...

Louis

Re: [Bashdb-devel] colon-equal assignment in emacs/Makefile.am

[Rocky B. <roc...@gm...>]

I used this when I was trying to make the Makefile more efficient. A :=
assignment is done once, whereas = causes multiple substitutions. For
example
EXTRA_DIST with := has the substituted value and after its assignment, the
value of check_DATA is not looked up on subsequent uses of EXTRA_DIST. You
can even change the value of check_DATA and the value of EXTRA_DIST won't
change.

However, a problem with using := is that BSD doesn't understand it. So you
you want to go back to using = for portability that's fine.

On 7/12/07, Masatake YAMATO <je...@gy...> wrote:
>
> `:=' is used in emacs/Makefile.am. I cannot find any reason why `=' is
> not enough here. Could you tell me the reason?
>
> --- Makefile.am 22 Jan 2007 03:06:00 +0900      1.5
> +++ Makefile.am 12 Jul 2007 13:25:19 +0900
> @@ -15,11 +15,11 @@
> #   Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA.
> #$Id: Makefile.am,v 1.5 2007/01/20 12:02:03 rockyb Exp $
>
> -check_DATA := bashdb-test.el bashdb-test.el.in elk-test.el
> -EXTRA_DIST := bashdb.el $(check_DATA)
> -ELCFILES  :=  bashdb.elc
> +check_DATA = bashdb-test.el bashdb-test.el.in elk-test.el
> +EXTRA_DIST = bashdb.el $(check_DATA)
> +ELCFILES  =  bashdb.elc
> if INSTALL_EMACS_LISP
> -lisp_LISP := bashdb.el
> +lisp_LISP = bashdb.el
> endif
>
> test: check
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

[Bashdb-devel] colon-equal assignment in emacs/Makefile.am

[Masatake Y. <je...@gy...>]

`:=' is used in emacs/Makefile.am. I cannot find any reason why `=' is 
not enough here. Could you tell me the reason?

--- Makefile.am	22 Jan 2007 03:06:00 +0900	1.5
+++ Makefile.am	12 Jul 2007 13:25:19 +0900	
@@ -15,11 +15,11 @@
 #   Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA.
 #$Id: Makefile.am,v 1.5 2007/01/20 12:02:03 rockyb Exp $
 
-check_DATA := bashdb-test.el bashdb-test.el.in elk-test.el
-EXTRA_DIST := bashdb.el $(check_DATA)
-ELCFILES  :=  bashdb.elc
+check_DATA = bashdb-test.el bashdb-test.el.in elk-test.el
+EXTRA_DIST = bashdb.el $(check_DATA)
+ELCFILES  =  bashdb.elc
 if INSTALL_EMACS_LISP
-lisp_LISP := bashdb.el
+lisp_LISP = bashdb.el
 endif
 
 test: check

[Bashdb-devel] bashdb.el

[Masatake Y. <je...@gy...>]

Hi, all

I've asked GNU Emacs maintainers and bash maintainer to remove bashdb.el from 
their products because users may confuse the existence of 3 versions of bashdb.el.
Kindly the maintainers have accepted my request.

So now, try the bashdb.el bundled with bashdb and report its bugs HERE.
Aside of Rocky, I'll take time to improve it.

Thanks.
Masatake YAMATO

Re: [Bashdb-devel] profiler

[Rocky B. <roc...@gm...>]

I don't think it would be hard to do, but doing a good job would be not be
trivial either. I wouldn't do it on top of bashdb since that would
ultimately be  too slow . A cardinal rule of monitor tools should be not to
trash the thing that is getting monitored.

However I  think such a profiler would  use many of the same things the
debugger uses: trap DEBUG,   BASH_SOURCE,  LINENO, FUNCNAME, and BASH_LEVEL.
For speed I'd save the data into C arrays, by writing a  builtin function,
similar to read_array/map array. But in contrast to that builtin, I don't
think it's necessary to convert the saved data into BASH structures. The
accumulated information could be written to a file at the end of program
execution. And the part that processes the data need not have anything to do
with bash.

A really great profiler would also get data on bash operations like its
array operations, substitution, subroutine call, subshell, expression
evaluations, various builtin operations and so on, but that would probably
involve hooking into the source code or working in conjunction with gprof.

As a crutch one could start with bashdb and strip it down  to use just
profiler essentials, but I think you'll only go so far this way; it might be
easier just to start from scratch. It depends on how one prefers to write
programs.

On 5/31/07, Masatake YAMATO <je...@gy...> wrote:
>
> Hi,
>
> Could you estimate how it is difficult to implement profiler (like prof
> or gprof) on bash?
>
>
> Masatake YAMATO
>
> -

[Bashdb-devel] profiler

[Masatake Y. <je...@gy...>]

Hi, 

Could you estimate how it is difficult to implement profiler (like prof
or gprof) on bash?


Masatake YAMATO

[Bashdb-devel] [bashdb - Help] RE: Input channel redirection in bashdb

[R. B. <ro...@pa...>]

SourceForge.net writes:
 > 
 > Read and respond to this message at: 
 > https://sourceforge.net/forum/message.php?msg_id=4302500
 > By: jploski
 > 
 > Thanks for the explanations. I think that the -x/--cmdfile option would
 > be insufficient for the purpose of controlling the debugger backend from a frontend
 > application. However, reimplementing -t/--tty to match gdb would help. I think
 > I'll look into that on the weekend. The question is whether the meaning of -t/--tty
 > should be changed or a new option introduced, as such a change would not be
 > backwards-compatible.

I do appreciate your concern for keeping compatibility, in this
particular case I don't think it warrants it. If there is a
project/community that relies on bashdb (let alone the behavior of
--tty), I am not aware of it. Before for a release I generally send an
announcement of what's changed and ask folks to try things out. So
people who miss this posting will get another reminder.

Furthermore, It always was a stated goal to be compatibile with *gdb*
(not bashdb ;-) unless there's good reason not to. My not
reading/understanding the gdb and its manual properly doesn't
constitute a good reason.

Lastly this kind of incompatible change has some precident. Initially
the thing that made debugging even conceivable (trap DEBUG) was a bit
flawed in that initially you stopped after the statement rather than
before. (For other signals like HUP or INT stopping after is of course
the right thing to do.) But I too was concerned about compatibility
and recall suggesting inventing another psuedo signal. What was done
was just to change the semantics of trap DEBUG, and I don't recall
in that situation anyone being annoyed. 

 - - -

As for redoing the code, if you undertake to make the correction,
thanks!

I think/hope it's pretty straightforward and possibly even easier than
what's there now. Currently the code does a check tty-ness. Instead
I'd just check to make sure that what was given is readable and
writable (-r -w) and then redirect stdin and stout to that. Note that
redirecting stdin and stdout won't always be effective becuase scripts
may do their own redirection. An important case in point is configure
scripts. 


However one should keep the *debugger's* tty the same which may mean
setting them to the current tty if the debugger is using stdin and
stdout for its output or has a tty associated with it.

The debugger's output routines already understand one may write to a
tty. See files dbg-log.inc and dbg-io.inc and _Dbg_msg.

Some regression test will have to get changed. In particular
test/misc.cmd, test/misc.right and test/lopts.right since the meaning
of --tty will change.

Good luck!

Re: [Bashdb-devel] bashdb 3.1-0.08 test failures under cygwin

[Rocky B. <roc...@gm...>]

Comments in line .

On 4/28/07, Eric Blake <eb...@by...> queries and avows:
>
> According to Rocky Bernstein on 4/24/2007 2:08 AM:
> > I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and
> > -O2 optimization). I was able to run the regression tests without any
> > errors both on bashdb 3.1-0.08 and current CVS sources.
> >
> > On cygwin where I noticed a failure, I was using the installed bash from
> > the Interent. Furthermore  bashdb wasn't using readarray the C-compiled
> > extension.
>
> Have you had any success getting cygwin bash to use loadable modules, such
> as readarray?


I deliberately did not  because there was a failure and I wanted to rule out
the possibility of this being caused by a readarray bug. Since it failed
without readarray, I fail to see how compiling readarry would fix  the
problem! And unlikeliness aside,  I'm not sure how helpful it would have
been to know that.

Furthermore, my recollection is that cygwin ships bashdb with readarray
compiled. It is one of the few distributions to do that - thank you very
much!

(In my own experience using readarray  greatly speeds up initial load time.
With luck and probably lots of persistence on Misatake's part, it will get
back into bash proper at some point.)

>
> > Given this, right now the evidence suggests that the problem mentioned
> > in this thread is in the bash 3.2.15 binary on cygwin.
>
> Indeed it was.  There are latent bugs in the bash source code, where
> various builtins leak output to the wrong file if stdio is not line
> buffered; but cygwin bash had a local patch that did just that in order to
> fix another bug where builtins incorrectly used text mode instead of
> binary mode to talk over pipes.  I've uploaded a new version of bash for
> cygwin that has the problem with builtins fixed, and verified that the
> bashdb testsuite passes again.



long rant...

My take is that there are a couple of lessons here. First, test suites are
good. They help you find bugs and verify the correct working of a program.
Second, this is not the first time the test suite for bashdb has shown a
presence of a bash bug. The bash test suite, while useful, has clearly been
a bit lacking.

Back when I was hacking on bash to add better debugger run-time support and
the timestamped history, I made a stab at improving the bash test suite so
it would be more automatic by not complaining as much when there is no
problem, make running tests individually easier, and use more of the
standard auto* test framework. Alas those changes didn't make it back into
the source.

It would be wise before a bash release to try out bashdb and run its test
suite. Not just because it would be a nice thing to do for bashdb (or more
precisely its users), but because it constitutes a large bash program that's
freely available in GPL; in that category it isone of the few that does come
with regression tests!

It is not clear to me that before a general bash release, there is  testing
done using such a large complete bash program. Small unit tests are great,
especially when they are carefully crafted and religiously applied via
test-driven development (which is probably not the case here). But a second
independent confirmation would be nice too.

Alas, I don't have the time (nor find it satisfying)  to keep tabs on the
bugs bash introduced between releases. Perhaps there's a kinder, more
tolerant soul out there who could help the community out by undertaking such
a task.

--
> Don't work too hard, make some time for fun as well!


I'm not that good - I have to work hard in order to get anything done.

Eric Blake             eb...@by...
>
>
>

Re: [Bashdb-devel] bashdb 3.1-0.08 test failures under cygwin

[Eric B. <eb...@by...>]

According to Rocky Bernstein on 4/24/2007 2:08 AM:
> I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and=
=20
> -O2 optimization). I was able to run the regression tests without any
> errors both on bashdb 3.1-0.08 and current CVS sources.
>=20
> On cygwin where I noticed a failure, I was using the installed bash fro=
m
> the Interent. Furthermore  bashdb wasn't using readarray the C-compiled=

> extension.

Have you had any success getting cygwin bash to use loadable modules, suc=
h
as readarray?

>=20
> Given this, right now the evidence suggests that the problem mentioned
> in this thread is in the bash 3.2.15 binary on cygwin.

Indeed it was.  There are latent bugs in the bash source code, where
various builtins leak output to the wrong file if stdio is not line
buffered; but cygwin bash had a local patch that did just that in order t=
o
fix another bug where builtins incorrectly used text mode instead of
binary mode to talk over pipes.  I've uploaded a new version of bash for
cygwin that has the problem with builtins fixed, and verified that the
bashdb testsuite passes again.

--=20
Don't work too hard, make some time for fun as well!

Eric Blake             eb...@by...

Re: [Bashdb-devel] bashdb 3.1-0.08 test failures under cygwin

[Rocky B. <roc...@gm...>]

I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and  -O2
optimization). I was able to run the regression tests without any errors
both on bashdb 3.1-0.08 and current CVS sources.

On cygwin where I noticed a failure, I was using the installed bash from the
Interent. Furthermore  bashdb wasn't using readarray the C-compiled
extension.

Given this, right now the evidence suggests that the problem mentioned in
this thread is in the bash 3.2.15 binary on cygwin.

On 4/19/07, Rocky Bernstein <roc...@gm...> wrote:
>
> I spent a little time looking at this after a very long day at work. Alas
> I'm too tired to investigate further so I'll just report what I know at
> present.
>
> In short, as best as I can tell I think this is a bug in bash. Details are
> below, but if things were working before and with the latest round of
> patches things got broken, it would indicate that either bash introduced a
> bug or there is something invalid that bashdb is doing  that causes bash to
> behave badly. Although I tried this on cygwin, but it  would be interesting
> to try to compile on a different platform to see if similar failures occur.
>
> Some details follow. At the line mentioned, line 944 of dbg-cmd.inc, I
> turned on set -x tracing. Basically I added this:
>   export PS4='(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]}\n'
>   set -x
> and a matching set +x later on. The attached patch might be of help here.
>
> To run just the failing program one can go into the test directory and run
> "./brkpt2.tests"
>
> Here is what I see near the failure:
>
> ...
> + ### another x command...
> + x j
> (((((../dbg-cmds.inc:946): _Dbg_do_x
> _Dbg_is_var j
> (((((../dbg-fns.inc:126): _Dbg_is_var
> declare -p j
> (((((../dbg-fns.inc:127): _Dbg_is_var
> [[ 0 != 0 ]]
> (((((../dbg-fns.inc:130): _Dbg_is_var
> echo 1
> ((((../dbg-cmds.inc:946): _Dbg_do_x
> ((  declare -i j="1"
> 1  ))
> ../dbg-cmds.inc: line 946: declare -i j="1"
> 1 : syntax error in expression (error token is "j="1"
> 1 ")
>
> What's wrong here is that line 946 is not " (( declare -i j="1" .... but
>
>  if (( `_Dbg_is_var $_Dbg_expr` )) ; then
>
> So what seems to be happening is that the wrong text is getting
> substituted back inside the backtick. What you should have seen was (( 1 ))
> because there was that "echo 1".  Interestingly whenever _Dbg_is_var decides
> to run "echo 0" instead of "echo 1", that does get substituted back
> correctly.
>
> I'll attach a log of my run. Finally, I don't know if this is related, but
> I seem to be getting "out of resource" errors after running the tests.
>
>        5 [main] sh 64760 fork: child -1 - CreateProcessA failed, errno 11
> ../dbg-pre.inc: fork: Resource temporarily unavailable
>       5 [main] sh 64676 fork: child -1 - CreateProcessA failed, errno 11
>
> With Windows ,one never knows what's going on.
>
>
>
>
> On 4/19/07, Eric Blake <eb...@by...> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I was trying to upgrade the cygwin installation of bashdb to the latest
> > release, and encountered 2 test failures atop bash-3.2.15.  I'm not
> > familiar enough with the bashdb sources to know where to look for the
> > cause of these two failures, but since they all mention dbg-cmds.incline
> > 944, I wonder if there is a bug there.  Any ideas?
> >
> > checking brkpt1...
> > checking brkpt2...
> > - --- /home/eblake/bashdb-3.1_0.08-1/build/test/brkpt2.check    2007-04-19
> > 06:42:53.453125000 -0600
> > +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/brkpt2.right
> > 2007-01-19 20:43:30.000000000 -0700
> > @@ -195,19 +195,13 @@
> > 11:    local -i j=i+1
> > + ### another x command...
> > + x j
> > - -../dbg-cmds.inc: line 944: ((: declare -i j="1"
> > - -1 : syntax error in expression (error token is "j="1"
> > - -1 ")
> > - -1
> > +declare -i j="1"
> > + ### another x command (+5 than value above) ...
> > + x j+5
> > 6
> > + ### x command of string y
> > + x y
> > - -../dbg-cmds.inc: line 944: ((: declare -- y="b"
> > - -1 : syntax error in expression (error token is "y="b"
> > - -1 ")
> > - -y
> > +declare -- y="b"
> > + ### x of a function ...
> > + x fn2
> > fn2 ()
> > FAIL: run-brkpt
> >
> > - --- /home/eblake/bashdb-3.1_0.08-1/build/test/command.check
> > 2007-04-19
> > 06:44:10.843750000 -0600
> > +++ /home/eblake/bashdb-
> > 3.1_0.08-1/src/bashdb-3.1-0.08/test/command.right
> > 2006-12-03 15:30:52.000000000 -0700
> > @@ -20,10 +20,7 @@
> > + continue
> > Breakpoint 1 hit (1 times).
> > + x x
> > - -../dbg-cmds.inc: line 944: ((: declare -- x="22"
> > - -1 : syntax error in expression (error token is "x="22"
> > - -1 ")
> > - -22
> > +declare -- x="22"
> > (dbg-test1.sh:23):
> > 23:    y=23
> > + #
> > FAIL: run-command
> >
> > - --
> > Don't work too hard, make some time for fun as well!
> >
> > Eric Blake             eb...@by...
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.5 (Cygwin)
> > Comment: Public key at home.comcast.net/~ericblake/eblake.gpg<http://home.comcast.net/%7Eericblake/eblake.gpg>
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGJ2ow84KuGfSFAYARAok2AJ9jZn/f4/EDZHXQBOaQyIhgSqLS2wCgqV4O
> > Vw3+oI0N6WeoE9jQps34V4Y=
> > =Fl9N
> > -----END PGP SIGNATURE-----
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Bashdb-devel mailing list
> > Bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/bashdb-devel
> >
>
>
>

Re: [Bashdb-devel] bashdb 3.1-0.08 test failures under cygwin

[Rocky B. <roc...@gm...>]

I spent a little time looking at this after a very long day at work. Alas
I'm too tired to investigate further so I'll just report what I know at
present.

In short, as best as I can tell I think this is a bug in bash. Details are
below, but if things were working before and with the latest round of
patches things got broken, it would indicate that either bash introduced a
bug or there is something invalid that bashdb is doing  that causes bash to
behave badly. Although I tried this on cygwin, but it  would be interesting
to try to compile on a different platform to see if similar failures occur.

Some details follow. At the line mentioned, line 944 of dbg-cmd.inc, I
turned on set -x tracing. Basically I added this:
  export PS4='(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]}\n'
  set -x
and a matching set +x later on. The attached patch might be of help here.

To run just the failing program one can go into the test directory and run
"./brkpt2.tests"

Here is what I see near the failure:

...
+ ### another x command...
+ x j
(((((../dbg-cmds.inc:946): _Dbg_do_x
_Dbg_is_var j
(((((../dbg-fns.inc:126): _Dbg_is_var
declare -p j
(((((../dbg-fns.inc:127): _Dbg_is_var
[[ 0 != 0 ]]
(((((../dbg-fns.inc:130): _Dbg_is_var
echo 1
((((../dbg-cmds.inc:946): _Dbg_do_x
((  declare -i j="1"
1  ))
../dbg-cmds.inc: line 946: declare -i j="1"
1 : syntax error in expression (error token is "j="1"
1 ")

What's wrong here is that line 946 is not "(( declare -i j="1" .... but

 if (( `_Dbg_is_var $_Dbg_expr` )) ; then

So what seems to be happening is that the wrong text is getting substituted
back inside the backtick. What you should have seen was (( 1 )) because
there was that "echo 1".  Interestingly whenever _Dbg_is_var decides to run
"echo 0" instead of "echo 1", that does get substituted back correctly.

I'll attach a log of my run. Finally, I don't know if this is related, but I
seem to be getting "out of resource" errors after running the tests.

      5 [main] sh 64760 fork: child -1 - CreateProcessA failed, errno 11
../dbg-pre.inc: fork: Resource temporarily unavailable
      5 [main] sh 64676 fork: child -1 - CreateProcessA failed, errno 11

With Windows ,one never knows what's going on.




On 4/19/07, Eric Blake <eb...@by...> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I was trying to upgrade the cygwin installation of bashdb to the latest
> release, and encountered 2 test failures atop bash-3.2.15.  I'm not
> familiar enough with the bashdb sources to know where to look for the
> cause of these two failures, but since they all mention dbg-cmds.inc line
> 944, I wonder if there is a bug there.  Any ideas?
>
> checking brkpt1...
> checking brkpt2...
> - --- /home/eblake/bashdb-3.1_0.08-1/build/test/brkpt2.check    2007-04-19
> 06:42:53.453125000 -0600
> +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/brkpt2.right
> 2007-01-19 20:43:30.000000000 -0700
> @@ -195,19 +195,13 @@
> 11:    local -i j=i+1
> + ### another x command...
> + x j
> - -../dbg-cmds.inc: line 944: ((: declare -i j="1"
> - -1 : syntax error in expression (error token is "j="1"
> - -1 ")
> - -1
> +declare -i j="1"
> + ### another x command (+5 than value above) ...
> + x j+5
> 6
> + ### x command of string y
> + x y
> - -../dbg-cmds.inc: line 944: ((: declare -- y="b"
> - -1 : syntax error in expression (error token is "y="b"
> - -1 ")
> - -y
> +declare -- y="b"
> + ### x of a function ...
> + x fn2
> fn2 ()
> FAIL: run-brkpt
>
> - --- /home/eblake/bashdb-3.1_0.08-1/build/test/command.check   2007-04-19
> 06:44:10.843750000 -0600
> +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/command.right
> 2006-12-03 15:30:52.000000000 -0700
> @@ -20,10 +20,7 @@
> + continue
> Breakpoint 1 hit (1 times).
> + x x
> - -../dbg-cmds.inc: line 944: ((: declare -- x="22"
> - -1 : syntax error in expression (error token is "x="22"
> - -1 ")
> - -22
> +declare -- x="22"
> (dbg-test1.sh:23):
> 23:    y=23
> + #
> FAIL: run-command
>
> - --
> Don't work too hard, make some time for fun as well!
>
> Eric Blake             eb...@by...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGJ2ow84KuGfSFAYARAok2AJ9jZn/f4/EDZHXQBOaQyIhgSqLS2wCgqV4O
> Vw3+oI0N6WeoE9jQps34V4Y=
> =Fl9N
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

[Bashdb-devel] bashdb 3.1-0.08 test failures under cygwin

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was trying to upgrade the cygwin installation of bashdb to the latest
release, and encountered 2 test failures atop bash-3.2.15.  I'm not
familiar enough with the bashdb sources to know where to look for the
cause of these two failures, but since they all mention dbg-cmds.inc line
944, I wonder if there is a bug there.  Any ideas?

checking brkpt1...
checking brkpt2...
- --- /home/eblake/bashdb-3.1_0.08-1/build/test/brkpt2.check	2007-04-19
06:42:53.453125000 -0600
+++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/brkpt2.right
2007-01-19 20:43:30.000000000 -0700
@@ -195,19 +195,13 @@
 11:	local -i j=i+1
 + ### another x command...
 + x j
- -../dbg-cmds.inc: line 944: ((: declare -i j="1"
- -1 : syntax error in expression (error token is "j="1"
- -1 ")
- -1
+declare -i j="1"
 + ### another x command (+5 than value above) ...
 + x j+5
 6
 + ### x command of string y
 + x y
- -../dbg-cmds.inc: line 944: ((: declare -- y="b"
- -1 : syntax error in expression (error token is "y="b"
- -1 ")
- -y
+declare -- y="b"
 + ### x of a function ...
 + x fn2
 fn2 ()
FAIL: run-brkpt

- --- /home/eblake/bashdb-3.1_0.08-1/build/test/command.check	2007-04-19
06:44:10.843750000 -0600
+++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/command.right
2006-12-03 15:30:52.000000000 -0700
@@ -20,10 +20,7 @@
 + continue
 Breakpoint 1 hit (1 times).
 + x x
- -../dbg-cmds.inc: line 944: ((: declare -- x="22"
- -1 : syntax error in expression (error token is "x="22"
- -1 ")
- -22
+declare -- x="22"
 (dbg-test1.sh:23):
 23:	y=23
 + #
FAIL: run-command

- --
Don't work too hard, make some time for fun as well!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGJ2ow84KuGfSFAYARAok2AJ9jZn/f4/EDZHXQBOaQyIhgSqLS2wCgqV4O
Vw3+oI0N6WeoE9jQps34V4Y=
=Fl9N
-----END PGP SIGNATURE-----

[Bashdb-devel] A nicer GNU Emacs gdb interface

[R. B. <ro...@pa...>]

I was alerted to a nicer gdb interface that is available in Emacs 23
(and possibly Emacs 22). The Emacs Lisp routines are in file gdb-ui.el
and the name of the top-level Emacs command is "gdba" -- however if
everything is set right, running "gdb" will run "gdba".

I mention in case someone is interested in working on extending either
bashdb.el, pydb.el, or mdb.el to make use of the better UI. But beware
-- it looks like the underlying mechanism, a gdb "annotation level"
setting is going to be changed and phased out with something else.

Lament: there are about 6 different and incompatible GUI-to-debugger
interfaces. 

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

[Masatake Y. <je...@gy...>]

>  > 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

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

[Nick R. <ni...@sn...>]

 > 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

[Richard S. <rm...@gn...>]

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: [Bashdb-devel] removing bushdb related code in gud.el

[Masatake Y. <je...@gy...>]

>     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: [Bashdb-devel] removing bushdb related code in gud.el

[Rocky B. <roc...@gm...>]

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 <rm...@gn...> 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>.
>

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

[Richard S. <rm...@gn...>]

    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: [Bashdb-devel] removing bushdb related code in gud.el

[Rocky B. <roc...@gm...>]

On 2/25/07, Nick Roberts <ni...@sn...> 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.

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

[Nick R. <ni...@sn...>]

 > 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

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

[Masatake Y. <je...@gy...>]

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)))
-
-
-;; ======================================================================
-;;
-;; BASHDB support. See http://bashdb.sourceforge.net
-;;
-;; AUTHOR:	Rocky Bernstein <ro...@pa...>
-;;
-;; 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: [Bashdb-devel] bashdb.el

[Rocky B. <roc...@gm...>]

Thanks for your comments. It's rare for me to find such agreement!

I also can't help but notice and  find amusing which of the 3 bashdb.el's is
the oldest and least well maintained.

On 1/26/07, Masatake YAMATO <je...@gy...> wrote:
>
> > Advantages of not being part of GNU Emacs
> >
> >    - easier to affect a change (at least for me)
> >    -  more frequent releases for users
> >    - shorter turn-around time when a problem is found or an
> >    improvement/patch offered
> >
> > Some of the advantages may vary over time. In particular, bashdb
> releases
> > are currently much more frequent that GNU Emacs releases. Will that
> always
> > be the case? I don't know. However since bashdb is much much smaller
> than
> > GNU Emacs, it stands a good chance of being true.
> >
> > The  turn-around time to address/fix a problem is also a dynamically
> > changeable thing. Above I'm just observing that this is what the
> > currentsituation seems to be.
> >
> > Disadvantages of not being part of GNU Emacs
> >
> >    -  People are more knowledgeable about the workings of GNU Emacs ,
> >    GUD, and Emacs Lisp than most bashdb  folks are
> >    -  When GUD and GNU Emacs change, this code will get updated in
> >    conjunction with that (we hope) so...
> >    - Easier to keep code consistent with the currently installed GNU
> >    Emacs. In bashdb I guess some compatibility needs to happen across
> >    many  GNU Emacses
> >
> > Given the above advantages and disadvantages, I think the advantages of
> not
> > being part of GNU Emacs outweigh the disadvantages.
>
> I strongly agree with you. You wrote all what I'd like to wrote:)
>
> > But I'd like to hear the
> > comments of others. Should this be cross-posted to the emacs
> newsgroups  and
> > emacs developers groups?
>
> I think the answer is too obvious; we should remove bashdb.el from emacs.
>
> ;; Copyright (C) 2002, 2006 Rocky Bernstein (ro...@pa...)
> ;;                    and Masatake YAMATO (je...@gy...)
>
> Both two bashdb.el developers agree with the trade-off between being
> and not being part of GNU Emacs.
>
> If you still insist that we should ask the question on emacs-devel,
> tell me. If you don't insist, I'll start on tasks to remove bashdb.el
> from GNU Emacs. In stead removing I'd like to take more time to work
> on bashbd.el in bashdb.
>
> > And by they way, isn't there also a bashdb.el that gets distributed with
> > BASH?
>
> I have to think about this...I've just found bashdb.el in bash is
> written by me:
>
> ;;; bashdb.el --- Grand Unified Debugger mode for running bashdb
> ;; Copyright (C) 2000, 2001 Masatake YAMATO
>
> ;; Author: Masatake YAMATO <je...@gy...>
>
> So I have rigth to propose removing it from bash.
>
> Masatake
>

Re: [Bashdb-devel] bashdb.el

[Masatake Y. <je...@gy...>]

> Advantages of not being part of GNU Emacs
> 
>    - easier to affect a change (at least for me)
>    -  more frequent releases for users
>    - shorter turn-around time when a problem is found or an
>    improvement/patch offered
> 
> Some of the advantages may vary over time. In particular, bashdb releases
> are currently much more frequent that GNU Emacs releases. Will that always
> be the case? I don't know. However since bashdb is much much smaller than
> GNU Emacs, it stands a good chance of being true.
> 
> The  turn-around time to address/fix a problem is also a dynamically
> changeable thing. Above I'm just observing that this is what the
> currentsituation seems to be.
> 
> Disadvantages of not being part of GNU Emacs
> 
>    -  People are more knowledgeable about the workings of GNU Emacs ,
>    GUD, and Emacs Lisp than most bashdb  folks are
>    -  When GUD and GNU Emacs change, this code will get updated in
>    conjunction with that (we hope) so...
>    - Easier to keep code consistent with the currently installed GNU
>    Emacs. In bashdb I guess some compatibility needs to happen across
>    many  GNU Emacses
> 
> Given the above advantages and disadvantages, I think the advantages of not
> being part of GNU Emacs outweigh the disadvantages. 

I strongly agree with you. You wrote all what I'd like to wrote:)

> But I'd like to hear the
> comments of others. Should this be cross-posted to the emacs newsgroups  and
> emacs developers groups?

I think the answer is too obvious; we should remove bashdb.el from emacs.

;; Copyright (C) 2002, 2006 Rocky Bernstein (ro...@pa...) 
;;                    and Masatake YAMATO (je...@gy...)

Both two bashdb.el developers agree with the trade-off between being
and not being part of GNU Emacs.

If you still insist that we should ask the question on emacs-devel,
tell me. If you don't insist, I'll start on tasks to remove bashdb.el
from GNU Emacs. In stead removing I'd like to take more time to work
on bashbd.el in bashdb.

> And by they way, isn't there also a bashdb.el that gets distributed with
> BASH?

I have to think about this...I've just found bashdb.el in bash is 
written by me:

;;; bashdb.el --- Grand Unified Debugger mode for running bashdb
;; Copyright (C) 2000, 2001 Masatake YAMATO 

;; Author: Masatake YAMATO <je...@gy...>

So I have rigth to propose removing it from bash.

Masatake