Thread: [Cgdb-devel] CGDB GPL version.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello all,

Short question: What the is the GPL version under which cgdb is
released?
(GPLv2 or above, GPLv2, etc?)

- Gilboa

On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> Short question: What the is the GPL version under which cgdb is
> released?
> (GPLv2 or above, GPLv2, etc?)

Hi,

I don't think we ever really put any thought into it. You can assume
it's licensed under either of those terms as far as I'm concerned.

Bob Rossi

On Sun, 2007-08-26 at 11:55 -0400, Bob Rossi wrote:
> On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> > Short question: What the is the GPL version under which cgdb is
> > released?
> > (GPLv2 or above, GPLv2, etc?)
> 
> Hi,
> 
> I don't think we ever really put any thought into it. You can assume
> it's licensed under either of those terms as far as I'm concerned.
> 
> Bob Rossi

OK. I'll put it up as GPLv2 or above.

P.S. Did you have any chance to take a log at the mock code I sent
yesterday?
(I'm doing a mock code just to approve the general concept)

- Gilboa

On Sun, Aug 26, 2007 at 08:12:49PM +0300, Gilboa Davara wrote:
> On Sun, 2007-08-26 at 11:55 -0400, Bob Rossi wrote:
> > On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> > > Short question: What the is the GPL version under which cgdb is
> > > released?
> > > (GPLv2 or above, GPLv2, etc?)
> > 
> > Hi,
> > 
> > I don't think we ever really put any thought into it. You can assume
> > it's licensed under either of those terms as far as I'm concerned.
> > 
> > Bob Rossi
> 
> OK. I'll put it up as GPLv2 or above.
> 
> P.S. Did you have any chance to take a log at the mock code I sent
> yesterday?
> (I'm doing a mock code just to approve the general concept)

Hi Gilboa,

I did, i'm thinking about if that approach is worth while for cgdb at
the moment. I've done more thinking about the roadmap for CGDB since we
talked last.

cgdb is getting closer to the .7.0, which will signify that the
map/macro support is ready for prime time use. This represents the
design, implementation and use of libkui.

All of the .7 release will be focused on getting the next higher level
of key binding into cgdb. Originally this was called libcex, to
represent 'lib cgdb ex'. However, I'm thinking that name is going to
change as I'm not sure it is appropriate anymore. I'm not exactly sure
what I'm going to make this API accomplish. I have 2 choices,

  - Allow cgdb to capture multiple keys and bind them to a single 
    piece of hard coded functionality in cgdb. Think of how you move 
    windows in vim. <Ctrl-w>j is multiple keys, but translates to a 
    single command. This approach has the disadvantage that the user
    can't tell cgdb what keys map to what commands. It has the 
    advantage that while the user is typing a command, cgdb can pick
    up on the state of the command, and do specific things. Think
    about 'd/foo<Enter>' in vim. The d says 'delete the following text'.
  - Allow the user to fully specify what key or set of keys translates
    into what cgdb command. This would be a key/value pair in a piece
    of configuration. This is how mutt handles this. The advantage to
    this is that the user can specify any set of keys to make cgdb do
    what they want. Potentially down the road someone could make an
    emacs binding mode. The downside is, it would be more difficult 
    than a key/value pair implementation in order to provide context
    support for commands like 'd/foo<Enter>'. Although it is possible.

So, with that said, the next series of releases will basically undo the
work that you are doing here. Maybe you should just send in a patch that
adds supports for the new keys you want in the existing infrastructure.
Please feel free to persuade me otherwise.

One other thought, how does your implementation allow multiple keys to
bind to the same command?

Bob Rossi

On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> Hello all,
> 
> Short question: What the is the GPL version under which cgdb is
> released?
> (GPLv2 or above, GPLv2, etc?)
> 
> - Gilboa

Hey Gilboa, Bob & I talked about it, and it seems like we should just
stick with GPLv2 for now, since neither of us has read GPLv3.

-- 
Mike Mueller
mi...@su...

On Sun, 2007-08-26 at 19:49 -0400, Mike Mueller wrote:
> On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> > Hello all,
> > 
> > Short question: What the is the GPL version under which cgdb is
> > released?
> > (GPLv2 or above, GPLv2, etc?)
> > 
> > - Gilboa
> 
> Hey Gilboa, Bob & I talked about it, and it seems like we should just
> stick with GPLv2 for now, since neither of us has read GPLv3.
> 

OK. Thanks.
I'll make the Fedora/RHEL package as GPLv2.

- Gilboa

On Sun, 2007-08-26 at 14:20 -0400, Bob Rossi wrote:
> On Sun, Aug 26, 2007 at 08:12:49PM +0300, Gilboa Davara wrote:
> > On Sun, 2007-08-26 at 11:55 -0400, Bob Rossi wrote:
> > > On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> > > > Short question: What the is the GPL version under which cgdb is
> > > > released?
> > > > (GPLv2 or above, GPLv2, etc?)
> > > 
> > > Hi,
> > > 
> > > I don't think we ever really put any thought into it. You can assume
> > > it's licensed under either of those terms as far as I'm concerned.
> > > 
> > > Bob Rossi
> > 
> > OK. I'll put it up as GPLv2 or above.
> > 
> > P.S. Did you have any chance to take a log at the mock code I sent
> > yesterday?
> > (I'm doing a mock code just to approve the general concept)
> 
> Hi Gilboa,
> 
> I did, i'm thinking about if that approach is worth while for cgdb at
> the moment. I've done more thinking about the roadmap for CGDB since we
> talked last.
> 
> cgdb is getting closer to the .7.0, which will signify that the
> map/macro support is ready for prime time use. This represents the
> design, implementation and use of libkui.
> 
> All of the .7 release will be focused on getting the next higher level
> of key binding into cgdb. Originally this was called libcex, to
> represent 'lib cgdb ex'. However, I'm thinking that name is going to
> change as I'm not sure it is appropriate anymore. I'm not exactly sure
> what I'm going to make this API accomplish. I have 2 choices,
> 
>   - Allow cgdb to capture multiple keys and bind them to a single 
>     piece of hard coded functionality in cgdb. Think of how you move 
>     windows in vim. <Ctrl-w>j is multiple keys, but translates to a 
>     single command. This approach has the disadvantage that the user
>     can't tell cgdb what keys map to what commands. It has the 
>     advantage that while the user is typing a command, cgdb can pick
>     up on the state of the command, and do specific things. Think
>     about 'd/foo<Enter>' in vim. The d says 'delete the following text'.
>   - Allow the user to fully specify what key or set of keys translates
>     into what cgdb command. This would be a key/value pair in a piece
>     of configuration. This is how mutt handles this. The advantage to
>     this is that the user can specify any set of keys to make cgdb do
>     what they want. Potentially down the road someone could make an
>     emacs binding mode. The downside is, it would be more difficult 
>     than a key/value pair implementation in order to provide context
>     support for commands like 'd/foo<Enter>'. Although it is possible.
> 
> So, with that said, the next series of releases will basically undo the
> work that you are doing here. Maybe you should just send in a patch that
> adds supports for the new keys you want in the existing infrastructure.
> Please feel free to persuade me otherwise.

.... It sounds reasonable not do a mini-revolution in the key-mapping
code seconds before you are about to do a full revolution in the same
code.

Either way, I'll send out a series of TGDB_XXX and front-end enhancement
patches that will add a couple of additional commands to the :cgdb
interface.

> 
> One other thought, how does your implementation allow multiple keys to
> bind to the same command?

Most likely hard coded. (Using the existing hard-coded values)
Creating a fully dynamic, multiple-key-supporting system (ALA emacs)
should require a lot of work... and I wonder if it is even required -
read: cgdb users are most likely (IMHO, at least) vim users that want a
vim-like interface for their favorite (?) debugger and in turn, will
most likely use the :cgdb (:vim like) interface.
Never the less, my test group is composed by my team-mates (who love
cgdb ;)) and myself... so... well, did I say IMHO?

- Gilboa

On Tue, Aug 28, 2007 at 04:09:49PM +0300, Gilboa Davara wrote:
> On Sun, 2007-08-26 at 14:20 -0400, Bob Rossi wrote:
> > So, with that said, the next series of releases will basically undo the
> > work that you are doing here. Maybe you should just send in a patch that
> > adds supports for the new keys you want in the existing infrastructure.
> > Please feel free to persuade me otherwise.
> 
> .... It sounds reasonable not do a mini-revolution in the key-mapping
> code seconds before you are about to do a full revolution in the same
> code.
> 
> Either way, I'll send out a series of TGDB_XXX and front-end enhancement
> patches that will add a couple of additional commands to the :cgdb
> interface.

Great! Can't wait to see them.

Bob Rossi

Thread: [Cgdb-devel] CGDB GPL version.

cgdb-devel