bashdb-devel

[Bashdb-devel] bashdb.el

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

There are two M-x bashdb; one is distributed as part of bashdb, and
another will be distributed as part of the next version of GNU emacs.
I guess the users may be confused.

What is the best way to deal this situation?
My opinion is that it is better to remove M-x bashdb code from GNU emacs.
In stead I will add some code to the bashdb.el distributed as part of 
bashdb to make it work well with the CVS version of GNU Emacs.

Rocky, how do you think?

[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] bashdb.el

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

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

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

Let me close, by relating something that caused me to change bashdb.el. In a
way it fleshes out in detail some of the points above.

Recently someone reported a regexp problem in the pydb -equivalent Emacs
program. As part of fixing that, I decided we really should start adding a
regression test for this. As best as I can tell there are no unit tests for
GNU Emacs, and in fact I think one of Richard Stallman's complaints is that
folks aren't testing things in GNU Emacs. So I went over the regular
expression pattern in bashdb.el and added a unit test, at least for the part
that had been a bug.

I suppose I should have sent another patch for GNU Emacs, but the last time
I put in a patch it wasn't all that satisfying or quick. I had to send some
copyright release thing (having done so several times in the past), and I
got a complaint from RMS about how the ChangeLog entry was written,
something about listing function names in a file or something. All of this
spanned about a month.

And after all of that work, none of that code has seen light of day in terms
of a general release. So the thing I care about most really hasn't happened
(yet). And as we see, when it happens it will likely be obsolete code
because of the hassle (at least for me) of keeping this code up to date.

On 1/21/07, Masatake YAMATO <je...@gy...> wrote:
>
> There are two M-x bashdb; one is distributed as part of bashdb, and
> another will be distributed as part of the next version of GNU emacs.
> I guess the users may be confused.
>
> What is the best way to deal this situation?
> My opinion is that it is better to remove M-x bashdb code from GNU emacs.
> In stead I will add some code to the bashdb.el distributed as part of
> bashdb to make it work well with the CVS version of GNU Emacs.
>
> Rocky, how do you think?
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

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

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
>