cgdb-devel — Development activity -- bug reports, patches, related questions

Re: [Cgdb-devel] CGDB GPL version.

[Gilboa D. <gi...@gm...>]

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

Re: [Cgdb-devel] CGDB GPL version.

[Mike M. <mi...@su...>]

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

Re: [Cgdb-devel] CGDB GPL version.

[Bob R. <bob...@co...>]

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

Re: [Cgdb-devel] CGDB GPL version.

[Gilboa D. <gi...@gm...>]

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

Re: [Cgdb-devel] CGDB GPL version.

[Bob R. <bob...@co...>]

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

[Cgdb-devel] CGDB GPL version.

[Gilboa D. <gi...@gm...>]

Hello all,

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

- Gilboa

Re: [Cgdb-devel] [Patch] (1/2) Merge source_input keyboard interface with CCOMMAND interface.

[Gilboa D. <gi...@gm...>]

On 8/24/07, Bob Rossi <bob...@co...> wrote:
> On Thu, Aug 23, 2007 at 11:55:37PM +0300, Gilboa Davara wrote:
> > OK, more luck then brains on my part.
> > While redoing the patch I found a nice way to reduce the layering breakage.
> > This once should apply nicely against the current trunk.
>
> Hi Gilboa,
>
> I've looked over this patch. I'm not entirely sure what you are trying
> to accomplish, maybe you could shed some light for me.

OK, My bad. I should have added a a bit of info the patch. (I'm used
to sending fixes and not patches... so it'll take me some time to
adjust ;))

I want to the keyboard management infrastructure to use the same
COMMANDS interface the normal cgdb command interface does.
The reason for it is simple, I want support for a number of gdb
commands. (Start/stop/kill/Ctrl-C/etc) and as it stands, I'll have to
add each command twice, once into the command interface and another
into the switch/case inside source_input.  (And a third addition to
the TGDB infrastructure)

A short sample will be more effective. (Attached)


> For instance, what is the reason to not use the source_vscroll function to
> move a page up or down?

The current COMMANDS structure uses a static param.
Currently, when scrolling (half) page up/down, you pass non-static
signed integer offset to source_vscroll.
If I want bolt source_[vh]scroll into COMMANDS, they must accept
static parameter from COMMANDS. (Hence the _page version).

In the beginning I though about adding flags to source_[vh]scroll
offset. But given the fact that offset is signed, It would have made
the code much less readable.

> BTW, I think it's possible to ask the source window how big it is. That
> would be a more clever way of getting the height than calling the
> get_src_height() function.

/+1.

>
> Also, why pass the sview object to all of the configuration commands?
> It's always possible to simply call if_get_sview () if it's necessary.
>

In-order to create a single command interface that can handle anything
- from source windows redraw/resize/move/close to TGDB commands, I
need to add the sviewer pointer for source-window handling commands.

- Gilboa

Re: [Cgdb-devel] Small update for the cgdb site download section.

[Gilboa D. <gi...@gm...>]

On 8/24/07, Mike Mueller <mi...@su...> wrote:
> On Thu, Aug 23, 2007 at 11:00:50PM +0300, Gilboa Davara wrote:
> > On 8/23/07, Gilboa Davara <gi...@gm...> wrote:
> > > Hello Bob,
> > >
> > > Please add the following lines to the download section: (Just to alert
> > > RedHat/Fedora people that cgdb is supported by RedHat/CentOS/Fedora)
> > > (BTW, kudos for site update!)
> > >
> > > Fedora:
> > >
> > > Fedora's extra repository has an up-to-date CGDB package, maintained
> > > by Gilboa Davara. In-order to install it, as root:
> > >
> >
> > Sorry... Weird cut-and-paste error.
> >
> > ====================================================
> >
> > Fedora:
> >
> > Fedora's extra repository has an up-to-date CGDB package. In-order to
> > install it, as root:
> >
> > yum install cgdb.
> >
> >
> >
> > RedHat/CentOS (5.0):
> >
> > Fedora EPEL [1] repository has an up-to-date CGDB package. In-order to
> > install it, as root:
> >
> > 1. Add EPEL support to your existing RedHat/CentOS installation [2].
> > 2. yum install cgdb
> >
> > [1] http://fedoraproject.org/wiki/EPEL
> > [2] http://fedoraproject.org/wiki/EPEL/FAQ#howtouse
> >
> > Thanks,
> > - Gilboa
>
> I added these to the download page, thanks for the tips. :)
>
> --
> Mike Mueller
> mi...@su...

Thanks!

- Gilboa

Re: [Cgdb-devel] [Patch] (1/2) Merge source_input keyboard interface with CCOMMAND interface.

[Bob R. <bob...@co...>]

On Thu, Aug 23, 2007 at 11:55:37PM +0300, Gilboa Davara wrote:
> OK, more luck then brains on my part.
> While redoing the patch I found a nice way to reduce the layering breakage.
> This once should apply nicely against the current trunk.

Hi Gilboa,

I've looked over this patch. I'm not entirely sure what you are trying
to accomplish, maybe you could shed some light for me. 

For instance, what is the reason to not use the source_vscroll function to 
move a page up or down? 
BTW, I think it's possible to ask the source window how big it is. That
would be a more clever way of getting the height than calling the
get_src_height() function.

Also, why pass the sview object to all of the configuration commands? 
It's always possible to simply call if_get_sview () if it's necessary.

Thanks,
Bob Rossi

Re: [Cgdb-devel] Small update for the cgdb site download section.

[Mike M. <mi...@su...>]

On Thu, Aug 23, 2007 at 11:00:50PM +0300, Gilboa Davara wrote:
> On 8/23/07, Gilboa Davara <gi...@gm...> wrote:
> > Hello Bob,
> >
> > Please add the following lines to the download section: (Just to alert
> > RedHat/Fedora people that cgdb is supported by RedHat/CentOS/Fedora)
> > (BTW, kudos for site update!)
> >
> > Fedora:
> >
> > Fedora's extra repository has an up-to-date CGDB package, maintained
> > by Gilboa Davara. In-order to install it, as root:
> >
> 
> Sorry... Weird cut-and-paste error.
> 
> ====================================================
> 
> Fedora:
> 
> Fedora's extra repository has an up-to-date CGDB package. In-order to
> install it, as root:
> 
> yum install cgdb.
> 
> 
> 
> RedHat/CentOS (5.0):
> 
> Fedora EPEL [1] repository has an up-to-date CGDB package. In-order to
> install it, as root:
> 
> 1. Add EPEL support to your existing RedHat/CentOS installation [2].
> 2. yum install cgdb
> 
> [1] http://fedoraproject.org/wiki/EPEL
> [2] http://fedoraproject.org/wiki/EPEL/FAQ#howtouse
> 
> Thanks,
> - Gilboa

I added these to the download page, thanks for the tips. :)

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

Re: [Cgdb-devel] [Patch] (1/2) Merge source_input keyboard interface with CCOMMAND interface.

[Gilboa D. <gi...@gm...>]

On 8/23/07, Gilboa Davara <gi...@gm...> wrote:
> On 8/23/07, Bob Rossi <bob...@co...> wrote:
> > On Thu, Aug 23, 2007 at 08:54:35PM +0300, Gilboa Davara wrote:
> > > Hello all,
> > >
> > > I was over booked for a couple of days (RAID replacement, Workstation
> > > meltdown. v.short vacation, etc) so I didn't have time to finish this
> > > patch.
> >
> > Hope everything is better!
>
> Thanks ;)
>
> >
> > > The following series of patches (that will be pushed, one by one,
> > > during the week-end [knock wood]) will merge the keyboard
> > > (source_input) and cgdb (AKA vi-style) command interfaces creating a
> > > single, easily expandable command interface.
> >
> > Unfortunately, the patch doesn't apply cleanly to trunk. Could you do an
> > update, fix the conflicts, and send the patch in again?
> >
> > Thanks,
> > Bob Rossi
>
> Ouch.
> I've must have applied it against an old(er) copy of the trunk.
>
> I'll redo it ASAP.
>
> - Gilboa
>

OK, more luck then brains on my part.
While redoing the patch I found a nice way to reduce the layering breakage.
This once should apply nicely against the current trunk.

- Gilboa

Re: [Cgdb-devel] Small update for the cgdb site download section.

[Gilboa D. <gi...@gm...>]

On 8/23/07, Gilboa Davara <gi...@gm...> wrote:
> Hello Bob,
>
> Please add the following lines to the download section: (Just to alert
> RedHat/Fedora people that cgdb is supported by RedHat/CentOS/Fedora)
> (BTW, kudos for site update!)
>
> Fedora:
>
> Fedora's extra repository has an up-to-date CGDB package, maintained
> by Gilboa Davara. In-order to install it, as root:
>

Sorry... Weird cut-and-paste error.

====================================================

Fedora:

Fedora's extra repository has an up-to-date CGDB package. In-order to
install it, as root:

yum install cgdb.



RedHat/CentOS (5.0):

Fedora EPEL [1] repository has an up-to-date CGDB package. In-order to
install it, as root:

1. Add EPEL support to your existing RedHat/CentOS installation [2].
2. yum install cgdb

[1] http://fedoraproject.org/wiki/EPEL
[2] http://fedoraproject.org/wiki/EPEL/FAQ#howtouse

Thanks,
- Gilboa

[Cgdb-devel] Small update for the cgdb site download section.

[Gilboa D. <gi...@gm...>]

Hello Bob,

Please add the following lines to the download section: (Just to alert
RedHat/Fedora people that cgdb is supported by RedHat/CentOS/Fedora)
(BTW, kudos for site update!)

Fedora:

Fedora's extra repository has an up-to-date CGDB package, maintained
by Gilboa Davara. In-order to install it, as root:




-- 
Gilboa Davara
Mobile:  972 54 496 8909
Email:   <mailto:gi...@gm...>

Re: [Cgdb-devel] [Patch] (1/2) Merge source_input keyboard interface with CCOMMAND interface.

[Gilboa D. <gi...@gm...>]

On 8/23/07, Bob Rossi <bob...@co...> wrote:
> On Thu, Aug 23, 2007 at 08:54:35PM +0300, Gilboa Davara wrote:
> > Hello all,
> >
> > I was over booked for a couple of days (RAID replacement, Workstation
> > meltdown. v.short vacation, etc) so I didn't have time to finish this
> > patch.
>
> Hope everything is better!

Thanks ;)

>
> > The following series of patches (that will be pushed, one by one,
> > during the week-end [knock wood]) will merge the keyboard
> > (source_input) and cgdb (AKA vi-style) command interfaces creating a
> > single, easily expandable command interface.
>
> Unfortunately, the patch doesn't apply cleanly to trunk. Could you do an
> update, fix the conflicts, and send the patch in again?
>
> Thanks,
> Bob Rossi

Ouch.
I've must have applied it against an old(er) copy of the trunk.

I'll redo it ASAP.

- Gilboa

Re: [Cgdb-devel] [Patch] (1/2) Merge source_input keyboard interface with CCOMMAND interface.

[Bob R. <bob...@co...>]

On Thu, Aug 23, 2007 at 08:54:35PM +0300, Gilboa Davara wrote:
> Hello all,
> 
> I was over booked for a couple of days (RAID replacement, Workstation
> meltdown. v.short vacation, etc) so I didn't have time to finish this
> patch.

Hope everything is better!

> The following series of patches (that will be pushed, one by one,
> during the week-end [knock wood]) will merge the keyboard
> (source_input) and cgdb (AKA vi-style) command interfaces creating a
> single, easily expandable command interface.

Unfortunately, the patch doesn't apply cleanly to trunk. Could you do an
update, fix the conflicts, and send the patch in again?

Thanks,
Bob Rossi

[Cgdb-devel] [Patch] (1/2) Merge source_input keyboard interface with CCOMMAND interface.

[Gilboa D. <gi...@gm...>]

Hello all,

I was over booked for a couple of days (RAID replacement, Workstation
meltdown. v.short vacation, etc) so I didn't have time to finish this
patch.
The following series of patches (that will be pushed, one by one,
during the week-end [knock wood]) will merge the keyboard
(source_input) and cgdb (AKA vi-style) command interfaces creating a
single, easily expandable command interface.

The reason for not sending a huge blob patch is simple, the first
patch (this one) seem to break layering and I rather get it approved
before moving into the easier "push all the keyboard command into the
main CCOMMAND interface" and "add more gdb commands" parts.

- Gilboa

Re: [Cgdb-devel] [Patch] New command interface. (Was: Re: Add kill, start, Yes, No...)

[Gilboa D. <gi...@gm...>]

On 8/6/07, Bob Rossi <bob...@co...> wrote:
> On Mon, Aug 06, 2007 at 04:20:17PM +0300, Gilboa Davara wrote:
> > On 8/6/07, Bob Rossi <bob...@co...> wrote:
> > > On Sun, Aug 05, 2007 at 11:50:43PM +0300, Gilboa Davara wrote:
> > > > I'm not sure I got the question:
> > > > First patch cleans up the command code.
> > > > Tomorrow (or the day after - I'm been recovering from a massive RAID
> > > > upgrade) I'll be posting a second patch that will merge the key-store
> > > > and command interface.
> > >
> > > OK. Sounds good. What exactly will this patch do? I know you are saying
> > > 'key-store', I'm not sure what that means.
> >
> > Ouch... Had a bad Piglish day yesterday.
> > What I meant was: Merge the keyboard bind interface with the command
> > event handlers into a single event handler.
> > It should reduce the over-head of adding new commands/keyboard binds
> > (both code and performance wise) considerably.
>
> Well, I still don't fully understand what you mean. Could you provide an
> example of how this would work, and what you would modify? I want to
> make sure I don't waste your time by having you write a patch that I
> wouldn't want to apply.
>
> I'm not sure if this effects what you are thinking, but I have already
> implemented 90% of the mapping functionality. This provides map, imap,
> unmap and iunmap. It isn't currently documented because it doesn't work
> perfectly. The user can easily make a map that will cause cgdb to
> go into an infinate loop. When you use the term, "keyboard binds" are
> you thinking of mapping functionality or something more high level?
>
> Thanks,
> Bob Rossi

The idea is fairly simple:
Currently, TGDB_RUN is being executed from two different contexts:
- cgdb command interface. (get_command)
- keyboard interface. (source_input).
My plan is simple - merge the non vim parts (read: Start/stop/quit/add
brk/remove brk/etc) of source_input static case/switch line into
entries within get_command and add "keyboard" support to the CCOMMAND
structures.
Once done, adding a new command/static keyboard bind will only require
adding a new entry into the CCOMMAND array. (instead of adding
yet-another-case in source_input)

- Gilboa

Re: [Cgdb-devel] [Patch] New command interface. (Was: Re: Add kill, start, Yes, No...)

[Bob R. <bob...@co...>]

On Mon, Aug 06, 2007 at 04:20:17PM +0300, Gilboa Davara wrote:
> On 8/6/07, Bob Rossi <bob...@co...> wrote:
> > On Sun, Aug 05, 2007 at 11:50:43PM +0300, Gilboa Davara wrote:
> > > I'm not sure I got the question:
> > > First patch cleans up the command code.
> > > Tomorrow (or the day after - I'm been recovering from a massive RAID
> > > upgrade) I'll be posting a second patch that will merge the key-store
> > > and command interface.
> >
> > OK. Sounds good. What exactly will this patch do? I know you are saying
> > 'key-store', I'm not sure what that means.
> 
> Ouch... Had a bad Piglish day yesterday.
> What I meant was: Merge the keyboard bind interface with the command
> event handlers into a single event handler.
> It should reduce the over-head of adding new commands/keyboard binds
> (both code and performance wise) considerably.

Well, I still don't fully understand what you mean. Could you provide an
example of how this would work, and what you would modify? I want to
make sure I don't waste your time by having you write a patch that I
wouldn't want to apply.

I'm not sure if this effects what you are thinking, but I have already
implemented 90% of the mapping functionality. This provides map, imap,
unmap and iunmap. It isn't currently documented because it doesn't work
perfectly. The user can easily make a map that will cause cgdb to 
go into an infinate loop. When you use the term, "keyboard binds" are
you thinking of mapping functionality or something more high level?

Thanks,
Bob Rossi

Re: [Cgdb-devel] [Patch] New command interface. (Was: Re: Add kill, start, Yes, No...)

[Gilboa D. <gi...@gm...>]

On 8/6/07, Bob Rossi <bob...@co...> wrote:
> On Sun, Aug 05, 2007 at 11:50:43PM +0300, Gilboa Davara wrote:
> > I'm not sure I got the question:
> > First patch cleans up the command code.
> > Tomorrow (or the day after - I'm been recovering from a massive RAID
> > upgrade) I'll be posting a second patch that will merge the key-store
> > and command interface.
>
> OK. Sounds good. What exactly will this patch do? I know you are saying
> 'key-store', I'm not sure what that means.

Ouch... Had a bad Piglish day yesterday.
What I meant was: Merge the keyboard bind interface with the command
event handlers into a single event handler.
It should reduce the over-head of adding new commands/keyboard binds
(both code and performance wise) considerably.

- Gilboa

Re: [Cgdb-devel] [Patch] New command interface. (Was: Re: Add kill, start, Yes, No...)

[Bob R. <bob...@co...>]

On Sun, Aug 05, 2007 at 11:50:43PM +0300, Gilboa Davara wrote:
> On 8/2/07, Bob Rossi <bob...@co...> wrote:
> > On Tue, Jul 31, 2007 at 01:52:57PM +0300, Gilboa Davara wrote:
> > > On Mon, 2007-07-30 at 15:53 -0400, Bob Rossi wrote:
> > > > At a minimum, I at least ask each new developer if it's OK if this is
> > > > licensed under the GPL and if it's OK that I license it under a
> > > > different open source (http://www.opensource.org/licenses) approved license
> > > > in the future if I decide I want to.
> > >
> > > As long as it's OSS approved, the patches are yours.
> >
> > Gilboa, where you going to repost the other patches, or do you expect me
> > to figure them out from the patch we already applied? I was hoping you
> > were going to repost. Either way, no hurry, just wanted to clear that
> > up.
> >
> > Thanks,
> > Bob Rossi
> >
> 
> Hello Bob,
> 
> I'm not sure I got the question:
> First patch cleans up the command code.
> Tomorrow (or the day after - I'm been recovering from a massive RAID
> upgrade) I'll be posting a second patch that will merge the key-store
> and command interface.

OK. Sounds good. What exactly will this patch do? I know you are saying 
'key-store', I'm not sure what that means. 

> A couple of days later I plan on releasing a third patch that will add
> additional gdb features /commands. (kill/start/etc).
> 
> Is it OK by you?

OK, sounds perfect.

Thanks,
Bob Rossi

Re: [Cgdb-devel] [Patch] New command interface. (Was: Re: Add kill, start, Yes, No...)

[Gilboa D. <gi...@gm...>]

On 8/2/07, Bob Rossi <bob...@co...> wrote:
> On Tue, Jul 31, 2007 at 01:52:57PM +0300, Gilboa Davara wrote:
> > On Mon, 2007-07-30 at 15:53 -0400, Bob Rossi wrote:
> > > At a minimum, I at least ask each new developer if it's OK if this is
> > > licensed under the GPL and if it's OK that I license it under a
> > > different open source (http://www.opensource.org/licenses) approved license
> > > in the future if I decide I want to.
> >
> > As long as it's OSS approved, the patches are yours.
>
> Gilboa, where you going to repost the other patches, or do you expect me
> to figure them out from the patch we already applied? I was hoping you
> were going to repost. Either way, no hurry, just wanted to clear that
> up.
>
> Thanks,
> Bob Rossi
>

Hello Bob,

I'm not sure I got the question:
First patch cleans up the command code.
Tomorrow (or the day after - I'm been recovering from a massive RAID
upgrade) I'll be posting a second patch that will merge the key-store
and command interface.
A couple of days later I plan on releasing a third patch that will add
additional gdb features /commands. (kill/start/etc).

Is it OK by you?

- Gilboa

[Cgdb-devel] [Patch] New command interface. (Was: Re: Add kill, start, Yes, No...)

[Gilboa D. <gi...@gm...>]

On Mon, 2007-07-30 at 15:53 -0400, Bob Rossi wrote:
> At a minimum, I at least ask each new developer if it's OK if this is 
> licensed under the GPL and if it's OK that I license it under a
> different open source (http://www.opensource.org/licenses) approved license 
> in the future if I decide I want to.

As long as it's OSS approved, the patches are yours.

> 
> One other change, when you modify the behavior of CGDB, it's 
> important to put that information into the manual. You can modify
> doc/cgdb.texinfo and then type 'make'. That will generate cgdb.txt
> which you can then look over. If you have all the software necessary
> you can type 'make pdf' and it will make cgdb.pdf. For a trivial
> change like you have here, it should be fairly easy to do.

Before I release the final patch-set, I'll create a doc/pdf/man patch as
well.
(Though I'm not a native English speaker, so it'll be wise to double
check my grammar/syntax)

Either way, as requested, I'm breaking the mega patch into a series of
small(er) patches.

Patch 1:
Replaces the current command interface (non-sorted action_t array) with
a sorted array with smarter callback functions.
This should reduce the coder (and performance) over-header of
introducing more/complex gdb commands into the "vi" interface. (Or
should I call it the cgdb interface?)

If/when this patch is approved, I'll push the third patch - which adds
additional commands (and keystrokes) to the "vi" interface.


Patch2:

-  if (ioctl (fileno (stdout), TIOCGWINSZ, &screen_size) == -1)
+  /* Running under cgdb/ddd fix. */
+  if ((ioctl (fileno (stdout), TIOCGWINSZ, &screen_size) == -1) ||
+  		(!screen_size.ws_col) ||
+		(!screen_size.ws_row))

> I don't really understand the above change. Why was that necessary?
> What exactly does the comment mean?
 
This is rather ugly patch.
... But if you run cgdb under a second debugger that has no active tty
(E.g. Under gdb or ddd with no output window), the ioctl doesn't fail,
it just returns zero-filled screen_save (which in-turn, SIGSEGV all the
WIDTH-1 functions)
Question is, do we need to abort if no valid tty is present?

- Gilboa

[Cgdb-devel] [Patch] Add kill, start, Yes, No to tgdb/cgdb + small optimization.

[Gilboa D. <gi...@gm...>]

Hello all,

I had some free time to hack my favorite gdb front-end.
* New cgdb options:
	- :kill, :k, key "k": kill the current process.
	- :start, :st, key "S": (Re)start the debugger. Break at first line.
	- :yes, key "Y": Send "yes" to gdb.
		(E.g. "Kill the program being debugged? (y or n)")
	- :no, key "N": Send "no" to gdb. (Same as above)
* Replace :cmd using for(xxx) with qsort/bsearch.
* Known issues:
	- cgdb sourceview doesn't handle killed process.
		(Still behaves as if process is running)
	- man/info/README need to be updated.

- Gilboa

[Cgdb-devel] Our price - US $ 269.90 save: US $ 1529.10 ADOBE CREATIVE 2 PREMIUM

[Celeste L. <ma...@ac...>]

Our price US $ 269.90 save: $1529 adobe creative 3
http://dkeiror99.com

Re: [Cgdb-devel] Photo

[Joni J. <99...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
</HEAD>
<BODY>

Hello! I am bored tonight. I am nice girl that would like to chat with you. Email me at li...@im... only, because I am writing not from my personal email. To see my pics

</BODY></HTML>