Thread: [Cgdb-devel] CGDB 1.0 Proposal
Brought to you by:
bobbybrasko,
crouchingturbo
Menu
▾
▴
cgdb-devel
|
From: Mike M. <mmu...@cs...> - 2003-08-14 01:51:28
|
Hi Everyone,
Just wanted to get this discussion going. In the next week or two,
we should really identify what exactly CGDB version 1.0 will do.
The idea is that this should be doable in a matter of a couple
months, that it'll be fully documented, and basically feature
complete. Advanced features can be left for a possible second
revision, but we want to keep things simple right now.
I've got a list of features here, and I'm hoping Bob will add
anything that I've missed. If any of you have feedback and/or
additional suggestions, please send them. I'll maintain an updated
copy of this proposal, and it'll go on our web site when it's done.
Proposal:
The CGDB GUI should have the following features:
- Configurable:
o Config file containing :ex commands
o Key bindings for any :ex commands
o Color schemes
- Robust source viewer:
o Fast syntax highlighting
o Regular expression searching
o Token identification (for displaying data)
o Assembly view (source, asm, and mixed modes)
o Hyperlinking (for viewing help files)
- Windowing system:
o Arbitrary number of source windows
o Bindable to currently executing source
o Resizable. Movable?
o Inferior process window (tty)
- Macro support (vim-style)
- Support reloading a new inferior program (gdb 'file' command)
The TGDB library should have the following features:
- GDB Interfaces
o Annotate 2
o GDB/MI
- Support for advanced GUI features
o Reloading new inferior application
o Providing a TTY for the inferior window
o Providing assembly instruction as well as file:line info
- Well-thought out API that will never change
I know I'm missing some things, so hopefully Bob can fill them in.
Let me know what you guys think! When we have this figured out
completely, we can more accurately slap version numbers on our
releases. As well, it's important to get CGDB more solid-looking,
so that when people do use it, they get a good impression.
Documentation is going to be very important for this, as we've
already seen sites describing CGDB as poorly documented.
I'm excited to get working on it again!
Mike
|
|
From: Bob R. <bo...@br...> - 2003-08-15 02:34:58
|
Hi,
On Wed, Aug 13, 2003 at 09:41:06PM -0400, Mike Mueller wrote:
> Hi Everyone,
>=20
> Just wanted to get this discussion going. In the next week or two,=20
> we should really identify what exactly CGDB version 1.0 will do. =20
> The idea is that this should be doable in a matter of a couple=20
> months, that it'll be fully documented, and basically feature=20
> complete. Advanced features can be left for a possible second=20
> revision, but we want to keep things simple right now.
>=20
> I've got a list of features here, and I'm hoping Bob will add=20
> anything that I've missed. If any of you have feedback and/or=20
> additional suggestions, please send them. I'll maintain an updated=20
> copy of this proposal, and it'll go on our web site when it's done.
>=20
What you have here is great! A few suggestions, to add to the proposal.
They are actually not exactly 1.0 features. They are more on what is and
is not acceptable to add to cgdb.
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.
2. Documentation is also very important. CGDB/TGDB need to=20
support 2 different types of documentation.=20
a) Internal, describing algorithms, design decisions, interfaces .=
..
For the internal we could use doxygen ( of course ). If
anyone recommends anything else, please bring it up.
b) External, user manuals, HOWTO's, FAQ's, ...
For external, we should probably use the GNU documentation
standard.=20
http://gnu.ghks.de/software/texinfo/texinfo.html
I would defiantly be up to picking a different standard if
anyone can suggest it.
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 think we should somehow retain the copy write to all patches
received. Any opinions?
4. Coding standards.=20
For this we can go two different routes. Pick a coding standard or
don't. I prefer to have one. I don't really care which one it is,
I would like to hear someone else's opinion on this topic.
I only know of 2 coding standards. The Linux kernel, and GNU's.
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.
I understand that many of these ideas seem like overhead, but in the
end, there will be a good product thats well rounded, instead of just
another free software project.
So, if you think that some of these are too much for a small project,
and that its overboard, let me know.
Ok, on to the proposal, I like what you have here, I think under each
of your categories, we should give good examples of what we want to work
and what we don't expect to work.
> Proposal:
>=20
> The CGDB GUI should have the following features:
>=20
> - Configurable:
> o Config file containing :ex commands
- Put any command here that you can type in the status bar.
- Commands that don't make sense because cgdb is not
initialized will be ignored.
> 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
map j move_up_line=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.
Phew...
> o Color schemes
- Color schemes are sensitive. They are directly related to the
lexical analyzer of each language. We need to come up with a
set of different kind of tokens that the color schemes will
work with.
- Color schemes seem like a shortcut to
:set STRING_LITERAL=3DBLUE
:set CHAR_LITERAL=3DRED
...
o Border schemes
- Many terminals do not support nice borders. CGDB needs to be
able to show the user what is necessary without any special
terminal characters. Although they are nice, they should not
be necessary or hard coded.
>=20
> - 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)
>=20
> - Windowing system:
> o Arbitrary number of source windows
> o Bindable to currently executing source
> o Resizable. Movable?
> o Inferior process window (tty)
>=20
> - Macro support (vim-style)
>=20
> - Support reloading a new inferior program (gdb 'file' command)
>=20
The TGDB library is actually pretty simple. You covered most of it. Here
is a little more detail.
> The TGDB library should have the following features:
>=20
> - GDB Interfaces
> o Annotate 2
> o GDB/MI
o Make general design to allow easy plug/play.
- Annotate 1
- Annotate 3
>=20
> - Support for advanced GUI features
> o Reloading new inferior application
> o Providing a TTY for the inferior window
> o Providing assembly instruction as well as file:line info
> =20
> - 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.
>=20
> I know I'm missing some things, so hopefully Bob can fill them in. =20
> Let me know what you guys think! When we have this figured out=20
> completely, we can more accurately slap version numbers on our=20
> releases. As well, it's important to get CGDB more solid-looking,=20
> so that when people do use it, they get a good impression. =20
> Documentation is going to be very important for this, as we've=20
> already seen sites describing CGDB as poorly documented.
>=20
> I'm excited to get working on it again!
>=20
> Mike
Well I can't wait to get working on it either. We have a long way to go!
Once we get all this down, maybe we can make some decisions.
Thanks,
Bob Rossi
|
|
From: Peter K. <pe...@ko...> - 2003-08-15 14:36:11
|
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...>
|
|
From: Mike M. <mmu...@cs...> - 2003-08-15 19:41:32
|
On Thu, 14 Aug 2003, 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. I agree, but I think this isn't really an issue right now. It is definitely something to keep in mind during development. : 2. Documentation is also very important. CGDB/TGDB need to : support 2 different types of documentation. : a) Internal, describing algorithms, design decisions, interfaces ... : For the internal we could use doxygen ( of course ). If : anyone recommends anything else, please bring it up. : b) External, user manuals, HOWTO's, FAQ's, ... : For external, we should probably use the GNU documentation : standard. : http://gnu.ghks.de/software/texinfo/texinfo.html : I would defiantly be up to picking a different standard if : anyone can suggest it. Ok. I am not sure if doxygen is overkill or not, but I'm not opposed to using it. We could also just comment header files well, and write a text file or two about the design (in the CVS repository). : 4. Coding standards. : For this we can go two different routes. Pick a coding standard or : don't. I prefer to have one. I don't really care which one it is, : I would like to hear someone else's opinion on this topic. : : I only know of 2 coding standards. The Linux kernel, and GNU's. We currently have differing styles of code in CGDB, and I don't see it as a problem. As long as it's readable. : 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. : : :I understand that many of these ideas seem like overhead, but in the :end, there will be a good product thats well rounded, instead of just :another free software project. : :So, if you think that some of these are too much for a small project, :and that its overboard, let me know. My reaction to a lot of these suggestions is that they are overkill. However, if you don't mind putting the extra work in to make them happen, they don't hurt to have. This is a really small project, and I think it will always be (even if it becomes popular). Also, a lot of these are bridges we can cross in the future if it is necessary. Mike |
|
From: Bob R. <bo...@br...> - 2003-08-20 15:04:05
|
Well, what's the current proposal? (Keeeeppppp iiiiittttt gggooooiiiinnnnngggggg) Bobby On Fri, Aug 15, 2003 at 03:32:36PM -0400, Mike Mueller wrote: > On Thu, 14 Aug 2003, Bob Rossi wrote: >=20 > : 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. >=20 > I agree, but I think this isn't really an issue right now. It is=20 > definitely something to keep in mind during development. >=20 > : 2. Documentation is also very important. CGDB/TGDB need to=20 > : support 2 different types of documentation.=20 > : a) Internal, describing algorithms, design decisions, interface= s ... > : For the internal we could use doxygen ( of course ). If > : anyone recommends anything else, please bring it up. > : b) External, user manuals, HOWTO's, FAQ's, ... > : For external, we should probably use the GNU documentation > : standard.=20 > : http://gnu.ghks.de/software/texinfo/texinfo.html > : I would defiantly be up to picking a different standard if > : anyone can suggest it. >=20 > Ok. I am not sure if doxygen is overkill or not, but I'm not=20 > opposed to using it. We could also just comment header files well,=20 > and write a text file or two about the design (in the CVS=20 > repository). >=20 > : 4. Coding standards.=20 > : For this we can go two different routes. Pick a coding standard or > : don't. I prefer to have one. I don't really care which one it is, > : I would like to hear someone else's opinion on this topic. > : > : I only know of 2 coding standards. The Linux kernel, and GNU's. >=20 > We currently have differing styles of code in CGDB, and I don't see=20 > it as a problem. As long as it's readable. >=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. > : > : > :I understand that many of these ideas seem like overhead, but in the > :end, there will be a good product thats well rounded, instead of just > :another free software project. > : > :So, if you think that some of these are too much for a small project, > :and that its overboard, let me know. >=20 > My reaction to a lot of these suggestions is that they are overkill. =20 > However, if you don't mind putting the extra work in to make them=20 > happen, they don't hurt to have. >=20 > This is a really small project, and I think it will always be (even=20 > if it becomes popular). Also, a lot of these are bridges we can=20 > cross in the future if it is necessary. >=20 > Mike >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Cgdb-devel mailing list > Cgd...@li... > https://lists.sourceforge.net/lists/listinfo/cgdb-devel |
|
From: Bob R. <bo...@br...> - 2003-08-22 08:40:34
|
Hey guys, Another 1.0 proposal for TGDB is to have a readline replacement or work with the maintaner of readline ( Chet Ramey ) to make readline context driven. I am Emailing him about this but he is not very responsive. The readline replacement could be a fork of readline. Or we could just write a small readline like interface that doesn't really do all the features. Bob Rossi On Wed, Aug 20, 2003 at 09:45:02AM -0400, Bob Rossi wrote: > Well, what's the current proposal? > (Keeeeppppp iiiiittttt gggooooiiiinnnnngggggg) >=20 > Bobby >=20 >=20 > On Fri, Aug 15, 2003 at 03:32:36PM -0400, Mike Mueller wrote: > > On Thu, 14 Aug 2003, Bob Rossi wrote: > >=20 > > : 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. > >=20 > > I agree, but I think this isn't really an issue right now. It is=20 > > definitely something to keep in mind during development. > >=20 > > : 2. Documentation is also very important. CGDB/TGDB need to=20 > > : support 2 different types of documentation.=20 > > : a) Internal, describing algorithms, design decisions, interfa= ces ... > > : For the internal we could use doxygen ( of course ). If > > : anyone recommends anything else, please bring it up. > > : b) External, user manuals, HOWTO's, FAQ's, ... > > : For external, we should probably use the GNU documentation > > : standard.=20 > > : http://gnu.ghks.de/software/texinfo/texinfo.html > > : I would defiantly be up to picking a different standard if > > : anyone can suggest it. > >=20 > > Ok. I am not sure if doxygen is overkill or not, but I'm not=20 > > opposed to using it. We could also just comment header files well,=20 > > and write a text file or two about the design (in the CVS=20 > > repository). > >=20 > > : 4. Coding standards.=20 > > : For this we can go two different routes. Pick a coding standard = or > > : don't. I prefer to have one. I don't really care which one it is, > > : I would like to hear someone else's opinion on this topic. > > : > > : I only know of 2 coding standards. The Linux kernel, and GNU's. > >=20 > > We currently have differing styles of code in CGDB, and I don't see=20 > > it as a problem. As long as it's readable. > >=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. > > : > > : > > :I understand that many of these ideas seem like overhead, but in the > > :end, there will be a good product thats well rounded, instead of just > > :another free software project. > > : > > :So, if you think that some of these are too much for a small project, > > :and that its overboard, let me know. > >=20 > > My reaction to a lot of these suggestions is that they are overkill. = =20 > > However, if you don't mind putting the extra work in to make them=20 > > happen, they don't hurt to have. > >=20 > > This is a really small project, and I think it will always be (even=20 > > if it becomes popular). Also, a lot of these are bridges we can=20 > > cross in the future if it is necessary. > >=20 > > Mike > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_0= 1/01 > > _______________________________________________ > > Cgdb-devel mailing list > > Cgd...@li... > > https://lists.sourceforge.net/lists/listinfo/cgdb-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X