Re: [Cgdb-devel] CGDB 1.0 Proposal

[Peter K. <pe...@ko...>]

On Thu, Aug 14, 2003 at 10:27:27PM -0400, Bob Rossi wrote:
>    1. testing should be a key component in CGDB/TGDB.
>       TGDB is poorly tested. It does have a testsuite, but it basically
>       is a sanity checking device. For *every* new feature we add to
>       either tool, we need to add a testsuite entry. I don't know how
>       we are going to do this, but it will help with regressions.

Well, this should be fairly easy, since you guys work at a BLOODY
TESTING COMPANY!  Seriously though, as much as Vector's marketing says
otherwise, its pretty easy to write unit tests.

>    3. License and copy write issues.
>       CGDB/TGDB should clearly have stated with it, its license.
>       I personally think CGDB and TGDB should be under the GPL and all=20
>       the files that make them up marked accordingly.

I agree with the GPL choice, although technically we could pick any
license we want since we're not commingling code with GDB.

>       I think we should somehow retain the copy write to all patches
>       received. Any opinions?

This doesn't bother me, although it will make it easier if we ever want
to sign over the copyright to the FSF.  However, this might make it much
more difficult for 3rd parties to contribute code.  So, I'd start by
just keeping track of each individual patch, and the person who sent it
in.=20

>    5. Patch approval mailing list.
>       I think all patches should be mailed in, and one of us can apply
>       the patch. This way, we can make sure that the ChangeLog is done
>       correct, the coding standard is correct, and none of us are
>       getting lazy.

Do you mean for all of us to put patches on this list before checking
them in? =20

> >    - Configurable:
> >      o Key bindings for any :ex commands
>          - This will be a separate library. It should be able to read a
>          config file in ~/.cgdb ( for example .cgdbkb ) that the user
>          could edit. The user would be able to put a key sequence and a
>          function name that that key sequence would call. For example,
>          the default behavior of 'j' in CGDB is to move down a line. So
>          cgdb will export a function called move_down_line. The user
>          could change the default by doing
>=20
>          map j move_up_line=20
>=20
>          also, the library would be smart enough to turn 5j into move
>          line down 5 times. It would also be able to understand things
>          like <F5> <CR>. Obviously I am doing something much like vim.
>          The library could do it however it wants.

I'm a little confused as to why this is a seperate library, if it were
it would have to be a very thin library:
    - Key presses already come from curses, so they would have to be fed
    into the library
    - Key mappings are, by necessity, tightly bound to cgdb/tgdb.
    They've got to call some sort of callback function
    - At most you would have a library that you would feed
    keymaps/callbacks/keypresses into and it would work its magic.  It
    just seems like the issue might be complicated because you'd
    probably have to have some sort fo default callback to get all the
    other keypresses. =20

I'm not saying its not worth seperating out, but it'll be a small
library.

> >    - Robust source viewer:
> >      o Fast syntax highlighting
> >      o Regular expression searching
> >      o Token identification (for displaying data)
>        o A movable cursor.
>          - The cursor should be able to move around the screen. Instead
>            of just be on a line.=20
>          - The user should be able to perform actions on the token under
>            the cursor.=20
>            example.=20
>                a) Hit the '*' key to search for the next occurance of the
>                word under the cursor.
>                b) Perform one of CGDB's macro's substituting some special
>                sequence for the word under the cursor. ( In order to
>                print the word under the cursor )
>                c) Maybe in a generic way you should be able to access
>                the N'th word under the cursor. This would be helpful for
>                macro's.
> >      o Assembly view (source, asm, and mixed modes)
>        o Perform actions like :set wrap
> >      o Hyperlinking (for viewing help files)

Hyper linking?  Isn't that a little excessive?  Are we going to start
reading email next?

> >    - Well-thought out API that will never change
>        o Giving to the front end the proper callbacks and data=20
>        structures.
>          - The front end will get a 'struct breakpoint' structure.
>            Instead of a char * with some data in it.
>          - Callbacks will be put into place instead of a receiving all
>            commands at once.
>        o TGDB will be context driven. So multiple instances should work
>        in the same program.
>        o TGDB will be able to handle signals, or it will be able to
>        receive the signals from the main application.

Lets be a little reasonable.  The API is gonna change because the GDB
people keep deprecating the features we need/use.  Lets try to build an
API that can be easily expanded without breaking binary compatibility.
That is, we can hide things in allocated structures, leave extra void*
parameters if we think a function will be expanded, etc.

I've always liked starting with the data structures first.
Algorithms/interfaces tend to be obvious once you've got a good set of
data structures.

- Peter

--=20
Peter D. Kovacs <pe...@ko...>