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

[Cgdb-devel] TGDB architecture

[Alain M. <al...@qn...>]

Bonjour

	hum ... this is more of a test, to check subscribtion 8-)

Is part of TGDB desing, support for threaded clients ?
What is the recovery when gdb goes to debugger heaven ?

[Cgdb-devel] new config option 'showtgdbcommands'

[Bob R. <bo...@br...>]

Hi All,

I added a new config option to CGDB.
It is 'showtgdbcommands'. It can be set by
:set stc or :set nostc.

If it is set, when the GUI requests a command to be run, ( ex. by hitting
spacebar to set a breakpoint ) it will be displayed to the user. If the
option is not set ( the default ), the command will not be shown to the
user.

I committed the change, and personally like it set. :)

The only down side is that the name is not so great. Can anyone think of
a better name for the option?

Thanks,
Bob Rossi

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Bob R. <bo...@br...>]

Hi Ronald,

It appears you are right. It does work fine. My company firewall was
blocking your site for some reason. The worst part is, there is no error
from Setup.

Anyways, both me and a friend got to download and install it off of your
mirror. Thanks for the great work!

We are going to put the instructions on how to download it on
http://cgdb.sourceforge.net/
hopefully, people will find it useful.

Bob Rossi

On Wed, Sep 10, 2003 at 11:06:59AM +0200, Ronald Landheer-Cieslak wrote:
> On Tue, Sep 09, 2003 at 03:20:23PM -0400, Bob Rossi wrote:
> > Hi Ronald,
> >=20
> > I added your server http://rlc.unsane.co.uk/ in the section "User URL:"
> > and  added it to the section labeled "Available Download Sites".  I the=
n=20
> > selected it and then hit "next", I got the error
> >=20
> > "Unable to get setup.ini from <http://rlc.unsame.co.uk/>"
>                                                ^^^
> If that is really what it said, there's a typo in the URL.
> Other than that, I just verified, the file is there and I can download it=
=20
> from setup.. so I have no idea what's wrong..
>=20
> Perhaps you should try again later..?
>=20
> rlc
>=20
> --=20
> rugged, adj.:
> 	Too heavy to lift.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Ronald Landheer-C. <bly...@us...>]

On Tue, Sep 09, 2003 at 03:20:23PM -0400, Bob Rossi wrote:
> Hi Ronald,
> 
> I added your server http://rlc.unsane.co.uk/ in the section "User URL:"
> and  added it to the section labeled "Available Download Sites".  I then 
> selected it and then hit "next", I got the error
> 
> "Unable to get setup.ini from <http://rlc.unsame.co.uk/>"
                                               ^^^
If that is really what it said, there's a typo in the URL.
Other than that, I just verified, the file is there and I can download it 
from setup.. so I have no idea what's wrong..

Perhaps you should try again later..?

rlc

-- 
rugged, adj.:
	Too heavy to lift.

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Bob R. <bo...@br...>]

Hi Ronald,

I added your server http://rlc.unsane.co.uk/ in the section "User URL:"
and  added it to the section labeled "Available Download Sites".  I then=20
selected it and then hit "next", I got the error

"Unable to get setup.ini from <http://rlc.unsame.co.uk/>"

Do you know whats wrong?

Bob Rossi

On Tue, Sep 09, 2003 at 12:30:52PM -0400, Ronald Landheer-Cieslak wrote:
> 	of:=20
> 	58bd52d3df08977056b1d18dbe3cc7b7 *cgdb-0.3.4-1.patch
> 	http: //rlc.unsane.co.uk/cgdb-0.3.4-1.patch [...]=20
> 	Content:   (-4.90 points, 5 required)
> =00	X_AUTH_WARNING     (-0.4 points) Has a X-Authentication-Warning header
> 	X_LOOP             (0.0 points)  Has a X-Loop header
> 	IN_REP_TO          (-0.5 points) Has a In-Reply-To header
> 	EMAIL_ATTRIBUTION: Contains what looks like an email attribution
> =00	QUOTED_EMAIL_TEXT: Contains what looks like a quoted email text
> =00	MAILTO_WITH_SUBJ: Includes a link to send a mail with a subject
> =00	USER_AGENT_MUTT    (-2.5 points) User-Agent header indicates a non-sp=
am MUA (Mutt)
> 	REPLY_WITH_QUOTES  (-0.5 points) Reply with quoted text
> Sender: cgd...@li...
> Errors-To: cgd...@li...
> X-BeenThere: cgd...@li...
> X-Mailman-Version: 2.0.9-sf.net
> Precedence: bulk
> Reply-To: cgd...@li...
> List-Help: <mailto:cgd...@li...?subject=3Dhel=
p>
> List-Post: <mailto:cgd...@li...>
> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-devel>,
> 	<mailto: cgd...@li...?subject=3Dsubscribe>
> List-Id: Development activity -- bug reports,
> 	patches,
> 	related questions <cgdb-devel.lists.sourceforge.net>
> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-deve=
l>,
> 	<mailto: cgd...@li...?subject=3Dunsubscribe>
> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=3Dcgdb-=
devel>
> Date: Tue, 9 Sep 2003 18:41:14 +0200
>=20
> Some of the files are generated, but the useful (and non-transient) part =
of the
> patch is in the Makefile.am files.
> A patch of only those files is now available where the old one was:
> 58bd52d3df08977056b1d18dbe3cc7b7 *cgdb-0.3.4-1.patch
> http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch
>=20
> The old patch also patches configure.in, but you might want to look at th=
at
> a bit closer, as I only simplified it a bit, and adapted it to by dev=20
> environment - there are no changes in it that you will really need.
> (Sorry for the confusion)
>=20
> HTH
>=20
> rlc
>=20
> On Tue, Sep 09, 2003 at 12:01:24PM -0400, Bob Rossi wrote:
> > Hi Ronald,
> >=20
> > Thanks for the great work! I am glad to see that CGDB is useful to
> > people running cygwin.
> >=20
> > I was wondering about the patch you sent in.
> > Did you just regenerate the files using a new version of autoconf? Or
> > did you modify the files by hand?
> >=20
> > I am wondering because if I apply the patch to CGDB, it will be lost
> > next time I reconfigure the files.
> >=20
> > Bob Rossi
> >=20
> > On Tue, Sep 09, 2003 at 06:31:49AM -0400, Ronald Landheer-Cieslak wrote:
> > > 	10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
> > > 	http: //rlc.unsane.co.uk/cgdb-0.3.4-1.patch [...]=20
> > > 	Content:   (-4.90 points, 5 required)
> > > > 	X_LOOP             (0.0 points)  Has a X-Loop header
> > > 	IN_REP_TO          (-0.5 points) Has a In-Reply-To header
> > > 	EMAIL_ATTRIBUTION: Contains what looks like an email attribution
> > > > > 	REPLY_WITH_QUOTES  (-0.5 points) Reply with quoted text
> > > Sender: cgd...@li...
> > > Errors-To: cgd...@li...
> > > X-BeenThere: cgd...@li...
> > > X-Mailman-Version: 2.0.9-sf.net
> > > Precedence: bulk
> > > Reply-To: cgd...@li...
> > > List-Help: <mailto:cgd...@li...?subject=
=3Dhelp>
> > > List-Post: <mailto:cgd...@li...>
> > > List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-de=
vel>,
> > > 	<mailto: cgd...@li...?subject=3Dsubscrib=
e>
> > > List-Id: Development activity -- bug reports,
> > > 	patches,
> > > 	related questions <cgdb-devel.lists.sourceforge.net>
> > > List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-=
devel>,
> > > 	<mailto: cgd...@li...?subject=3Dunsubscr=
ibe>
> > > List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=3Dc=
gdb-devel>
> > > Date: Tue, 9 Sep 2003 12:57:59 +0200
> > >=20
> > > I previously forgot to attach the patch and the message I did attach =
it to=20
> > > is apparently too big.
> > >=20
> > > The patch is available here:
> > > 10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
> > > http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch
> > >=20
> > > HTH
> > >=20
> > > rlc
> > >=20
> > > On Tue, Sep 09, 2003 at 12:19:12PM +0200, Ronald Landheer-Cieslak wro=
te:
> > > > Hello all,
> > > >=20
> > > > While porting & packaging cgdb 0.3.3a and cgdb 0.3.4 for Cygwin, I =
ran into
> > > > a bug in the configury that makes it impossible to build cgdb outsi=
de of the
> > > > source directory. The attached patch fixes the problem.
> > > >=20
> > > > The Cygwin port of cgdb is available via Setup.exe at http://rlc.un=
sane.co.uk/=20
> > > > (add the url to the mirror list in Setup.exe). Setup itself is, of =
course,=20
> > > > available at http://cygwin.com/setup.exe
> > > >=20
> > > > HTH
> > > >=20
> > > > rlc
> > > >=20
> > > > NB: though cgf has vetoed the cgdb package and it will thus not be =
added to the
> > > >     official Cygwin net distro, I'll be happy to maintain a Cygwin =
port living
> > > >     on http://rlc.unsane.co.uk/ anyway - if you're interested.
> > > >=20
> > > > --=20
> > > > Decision maker, n.:
> > > > 	The person in your office who was unable to form a task force
> > > > 	before the music stopped.
> > > >=20
> > > >=20
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Cgdb-devel mailing list
> > > > Cgd...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
> > >=20
> > > --=20
> > > Oh, well, I guess this is just going to be one of those lifetimes.
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Cgdb-devel mailing list
> > > Cgd...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
>=20
>=20
>=20
> --=20
> "It's when they say 2 + 2 =3D 5 that I begin to argue."
> -- Eric Pepke
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Ronald Landheer-C. <bly...@us...>]

Some of the files are generated, but the useful (and non-transient) part of the
patch is in the Makefile.am files.
A patch of only those files is now available where the old one was:
58bd52d3df08977056b1d18dbe3cc7b7 *cgdb-0.3.4-1.patch
http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch

The old patch also patches configure.in, but you might want to look at that
a bit closer, as I only simplified it a bit, and adapted it to by dev 
environment - there are no changes in it that you will really need.
(Sorry for the confusion)

HTH

rlc

On Tue, Sep 09, 2003 at 12:01:24PM -0400, Bob Rossi wrote:
> Hi Ronald,
> 
> Thanks for the great work! I am glad to see that CGDB is useful to
> people running cygwin.
> 
> I was wondering about the patch you sent in.
> Did you just regenerate the files using a new version of autoconf? Or
> did you modify the files by hand?
> 
> I am wondering because if I apply the patch to CGDB, it will be lost
> next time I reconfigure the files.
> 
> Bob Rossi
> 
> On Tue, Sep 09, 2003 at 06:31:49AM -0400, Ronald Landheer-Cieslak wrote:
> > 	10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
> > 	http: //rlc.unsane.co.uk/cgdb-0.3.4-1.patch [...] 
> > 	Content:   (-4.90 points, 5 required)
> > > 	X_LOOP             (0.0 points)  Has a X-Loop header
> > 	IN_REP_TO          (-0.5 points) Has a In-Reply-To header
> > 	EMAIL_ATTRIBUTION: Contains what looks like an email attribution
> > > > 	REPLY_WITH_QUOTES  (-0.5 points) Reply with quoted text
> > Sender: cgd...@li...
> > Errors-To: cgd...@li...
> > X-BeenThere: cgd...@li...
> > X-Mailman-Version: 2.0.9-sf.net
> > Precedence: bulk
> > Reply-To: cgd...@li...
> > List-Help: <mailto:cgd...@li...?subject=help>
> > List-Post: <mailto:cgd...@li...>
> > List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-devel>,
> > 	<mailto: cgd...@li...?subject=subscribe>
> > List-Id: Development activity -- bug reports,
> > 	patches,
> > 	related questions <cgdb-devel.lists.sourceforge.net>
> > List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-devel>,
> > 	<mailto: cgd...@li...?subject=unsubscribe>
> > List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=cgdb-devel>
> > Date: Tue, 9 Sep 2003 12:57:59 +0200
> > 
> > I previously forgot to attach the patch and the message I did attach it to 
> > is apparently too big.
> > 
> > The patch is available here:
> > 10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
> > http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch
> > 
> > HTH
> > 
> > rlc
> > 
> > On Tue, Sep 09, 2003 at 12:19:12PM +0200, Ronald Landheer-Cieslak wrote:
> > > Hello all,
> > > 
> > > While porting & packaging cgdb 0.3.3a and cgdb 0.3.4 for Cygwin, I ran into
> > > a bug in the configury that makes it impossible to build cgdb outside of the
> > > source directory. The attached patch fixes the problem.
> > > 
> > > The Cygwin port of cgdb is available via Setup.exe at http://rlc.unsane.co.uk/ 
> > > (add the url to the mirror list in Setup.exe). Setup itself is, of course, 
> > > available at http://cygwin.com/setup.exe
> > > 
> > > HTH
> > > 
> > > rlc
> > > 
> > > NB: though cgf has vetoed the cgdb package and it will thus not be added to the
> > >     official Cygwin net distro, I'll be happy to maintain a Cygwin port living
> > >     on http://rlc.unsane.co.uk/ anyway - if you're interested.
> > > 
> > > -- 
> > > Decision maker, n.:
> > > 	The person in your office who was unable to form a task force
> > > 	before the music stopped.
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Cgdb-devel mailing list
> > > Cgd...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
> > 
> > -- 
> > Oh, well, I guess this is just going to be one of those lifetimes.
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Cgdb-devel mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-devel



-- 
"It's when they say 2 + 2 = 5 that I begin to argue."
-- Eric Pepke

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Bob R. <bo...@br...>]

Hi Ronald,

Thanks for the great work! I am glad to see that CGDB is useful to
people running cygwin.

I was wondering about the patch you sent in.
Did you just regenerate the files using a new version of autoconf? Or
did you modify the files by hand?

I am wondering because if I apply the patch to CGDB, it will be lost
next time I reconfigure the files.

Bob Rossi

On Tue, Sep 09, 2003 at 06:31:49AM -0400, Ronald Landheer-Cieslak wrote:
> 	10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
> 	http: //rlc.unsane.co.uk/cgdb-0.3.4-1.patch [...]=20
> 	Content:   (-4.90 points, 5 required)
> > 	X_LOOP             (0.0 points)  Has a X-Loop header
> 	IN_REP_TO          (-0.5 points) Has a In-Reply-To header
> 	EMAIL_ATTRIBUTION: Contains what looks like an email attribution
> > > 	REPLY_WITH_QUOTES  (-0.5 points) Reply with quoted text
> Sender: cgd...@li...
> Errors-To: cgd...@li...
> X-BeenThere: cgd...@li...
> X-Mailman-Version: 2.0.9-sf.net
> Precedence: bulk
> Reply-To: cgd...@li...
> List-Help: <mailto:cgd...@li...?subject=3Dhel=
p>
> List-Post: <mailto:cgd...@li...>
> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-devel>,
> 	<mailto: cgd...@li...?subject=3Dsubscribe>
> List-Id: Development activity -- bug reports,
> 	patches,
> 	related questions <cgdb-devel.lists.sourceforge.net>
> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/cgdb-deve=
l>,
> 	<mailto: cgd...@li...?subject=3Dunsubscribe>
> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=3Dcgdb-=
devel>
> Date: Tue, 9 Sep 2003 12:57:59 +0200
>=20
> I previously forgot to attach the patch and the message I did attach it t=
o=20
> is apparently too big.
>=20
> The patch is available here:
> 10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
> http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch
>=20
> HTH
>=20
> rlc
>=20
> On Tue, Sep 09, 2003 at 12:19:12PM +0200, Ronald Landheer-Cieslak wrote:
> > Hello all,
> >=20
> > While porting & packaging cgdb 0.3.3a and cgdb 0.3.4 for Cygwin, I ran =
into
> > a bug in the configury that makes it impossible to build cgdb outside o=
f the
> > source directory. The attached patch fixes the problem.
> >=20
> > The Cygwin port of cgdb is available via Setup.exe at http://rlc.unsane=
.co.uk/=20
> > (add the url to the mirror list in Setup.exe). Setup itself is, of cour=
se,=20
> > available at http://cygwin.com/setup.exe
> >=20
> > HTH
> >=20
> > rlc
> >=20
> > NB: though cgf has vetoed the cgdb package and it will thus not be adde=
d to the
> >     official Cygwin net distro, I'll be happy to maintain a Cygwin port=
 living
> >     on http://rlc.unsane.co.uk/ anyway - if you're interested.
> >=20
> > --=20
> > Decision maker, n.:
> > 	The person in your office who was unable to form a task force
> > 	before the music stopped.
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Cgdb-devel mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-devel
>=20
> --=20
> Oh, well, I guess this is just going to be one of those lifetimes.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

Re: [Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Ronald Landheer-C. <bly...@us...>]

I previously forgot to attach the patch and the message I did attach it to 
is apparently too big.

The patch is available here:
10dc3f028ae852529d8e2aab9ef0e838 *cgdb-0.3.4-1.patch
http://rlc.unsane.co.uk/cgdb-0.3.4-1.patch

HTH

rlc

On Tue, Sep 09, 2003 at 12:19:12PM +0200, Ronald Landheer-Cieslak wrote:
> Hello all,
> 
> While porting & packaging cgdb 0.3.3a and cgdb 0.3.4 for Cygwin, I ran into
> a bug in the configury that makes it impossible to build cgdb outside of the
> source directory. The attached patch fixes the problem.
> 
> The Cygwin port of cgdb is available via Setup.exe at http://rlc.unsane.co.uk/ 
> (add the url to the mirror list in Setup.exe). Setup itself is, of course, 
> available at http://cygwin.com/setup.exe
> 
> HTH
> 
> rlc
> 
> NB: though cgf has vetoed the cgdb package and it will thus not be added to the
>     official Cygwin net distro, I'll be happy to maintain a Cygwin port living
>     on http://rlc.unsane.co.uk/ anyway - if you're interested.
> 
> -- 
> Decision maker, n.:
> 	The person in your office who was unable to form a task force
> 	before the music stopped.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cgdb-devel mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-devel

-- 
Oh, well, I guess this is just going to be one of those lifetimes.

[Cgdb-devel] cgdb doesn't build outside of the source dir (patch attached)

[Ronald Landheer-C. <bly...@us...>]

Hello all,

While porting & packaging cgdb 0.3.3a and cgdb 0.3.4 for Cygwin, I ran into
a bug in the configury that makes it impossible to build cgdb outside of the
source directory. The attached patch fixes the problem.

The Cygwin port of cgdb is available via Setup.exe at http://rlc.unsane.co.uk/ 
(add the url to the mirror list in Setup.exe). Setup itself is, of course, 
available at http://cygwin.com/setup.exe

HTH

rlc

NB: though cgf has vetoed the cgdb package and it will thus not be added to the
    official Cygwin net distro, I'll be happy to maintain a Cygwin port living
    on http://rlc.unsane.co.uk/ anyway - if you're interested.

-- 
Decision maker, n.:
	The person in your office who was unable to form a task force
	before the music stopped.

Re: [Cgdb-devel] CGDB Development Methods (was Re: CGDB 1.0 Proposal)

[Bob R. <bo...@br...>]

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

Re: [bob@brasko.net: Re: [Cgdb-devel] [ 790050 ] segfault in filedlg - patch]

[Bob R. <bo...@br...>]

Hi Bartosz,

Hmmm, I see what you mean. CGDB does give an error. However, the curses
window does erase it. I don't know off of the top of my head what
the best course of action for this is.

We could try to write the error to standard error. Or shutdown curses,
write the error, and then open curses again.

I'll look into it.

Thanks,
Bob Rossi


On Wed, Aug 20, 2003 at 06:22:31PM +0200, Bartosz Zapalowski wrote:
> Hi Bob,
>=20
> I'm not working with Robert Lemmen. I didn't check Debian pages to see
> if there is already intent to package. My fault.
>=20
>=20
> There is another issue with cgdb, but this time I guess it's rather
> connected with xterm specific ncurses handling. In xterm when there's an
> error (like after ./cgdb -d /path/to/nonexistent/program) cgdb just
> quits and there is not error message. It's all okay on Linux console.
>=20
> By the way - if the bug in file dialog is already fixed, then close the
> bug on sf.net - it would make bug statistics nicier :).
>=20
> --=20
> Bartosz Zapalowski
> ba...@kl...

Re: [bob@brasko.net: Re: [Cgdb-devel] [ 790050 ] segfault in filedlg - patch]

[Bartosz Z. <ba...@kl...>]

Hi Bob,

I'm not working with Robert Lemmen. I didn't check Debian pages to see
if there is already intent to package. My fault.


There is another issue with cgdb, but this time I guess it's rather
connected with xterm specific ncurses handling. In xterm when there's an
error (like after ./cgdb -d /path/to/nonexistent/program) cgdb just
quits and there is not error message. It's all okay on Linux console.

By the way - if the bug in file dialog is already fixed, then close the
bug on sf.net - it would make bug statistics nicier :).

--=20
Bartosz Zapalowski
ba...@kl...

Re: [Cgdb-devel] [ 790050 ] segfault in filedlg - patch

[Bob R. <bo...@br...>]

Anyways, Here is the patch. I applied it to cvs, but that has had a
bunch of code applied to it since cgdb-0.3.4. So, you can either use=20
whats in cvs or patch what you have.

Index: tgdb/annotate-two/src/commands.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/cgdb/cgdb/tgdb/annotate-two/src/commands.c,v
retrieving revision 1.8
diff -w -u -r1.8 commands.c
--- tgdb/annotate-two/src/commands.c    19 Aug 2003 17:59:37 -0000  1.8
+++ tgdb/annotate-two/src/commands.c    20 Aug 2003 13:42:30 -0000
@@ -457,6 +457,10 @@
 }
=20
 void commands_send_gui_sources(struct commands *c, struct queue *q){
+   /* If the inferior program was not compiled with debug, then no sources
+    * will be available. If no sources are available, do not return the
+    * TGDB_UPDATE_SOURCE_FILES command. */
+   if ( queue_size ( c->source_files ) > 0 )
     tgdb_append_command ( q, TGDB_UPDATE_SOURCE_FILES, c->source_files );
 }

Thanks,
Bobby

On Wed, Aug 20, 2003 at 09:11:05AM -0400, Bob Rossi wrote:
> Hi Bartosz,
>=20
> Thanks for the patch. I have reproduced the problem you are seeing.
> I think you are right about saying the patch belongs in TGDB. I will
> look into fixing TGDB so that it returns TGDB_SOURCES_DENIED the
> first time, and not just every time after the first time.
>=20
> Also, because of this bug, I found another bug that needs to be fixed.
> The second time, when you actually do get the message
> "...No sources available...", you have to hit ESC or 'q' to get out of
> the file dialog mode, before you can hit any other keys ( CGDB thinks it
> is in the filedlg ). If the error occurs, I think it should leave you in
> CGDB's window.
>=20
> So, I'll try to fix these 2 bugs today.
>=20
> By the way, are you working with Robert Lemmen? I know he has done some
> work for packing CGDB with debian. I don't know exactly what he did, but
> I know he worked on it a little. His Email is rob...@se... if
> you want to find out what he is doing.
>=20
> Thanks for the heads up,
> Bob Rossi
>=20
>=20
> On Tue, Aug 19, 2003 at 09:36:56PM +0200, Bartosz Zapalowski wrote:
> > Hi
> >=20
> > Here's a patch that solves the bug #790050.
> >=20
> > I plan to package cgdb for Debian and have this package sponsored.
> > Because of that you can expect more patches from me, because I want no
> > bugs in programs I package, got it ;).
> >=20
> > This patch is rather a quick hack, and not the proper solution. However,
> > the source code is hard do hack, hence this workaround.
> >=20
> > The proper fix would be to patch tgdb sources. Try the following
> > *before* applying this patch:
> > $ cgdb
> > ESC, o
> > q
> > ESC, o
> >=20
> > As you can see, at first you get a blank screen. At a second 'o' command
> > you get
> > Error: No sources available! Was program compiled with debug?
> >=20
> > As I figured out, the problem is in annotate-two, which incorrectly
> > parses gdb output for the first time (or maybe it's gdb bad boy?).
> >=20
> > --=20
> > Bartosz Zapalowski
> > ba...@kl...
>=20
> > diff -ruN cgdb-0.3.4-old/cgdb/src/cgdb.c cgdb-0.3.4-new/cgdb/src/cgdb.c
> > --- cgdb-0.3.4-old/cgdb/src/cgdb.c	2003-06-24 03:25:35.000000000 +0200
> > +++ cgdb-0.3.4-new/cgdb/src/cgdb.c	2003-08-19 21:15:10.000000000 +0200
> > @@ -366,6 +366,12 @@
> > =20
> >                  if_clear_filedlg();
> > =20
> > +		if (queue_size (q) =3D=3D 0) {
> > +    		    if_display_message("Error:", 0, =20
> > +     			" No sources available! Was program compiled with debug?");
> > +		    break;
> > +		}
> > +
> >                  while ( queue_size ( q ) > 0 ) {
> >                      s =3D queue_pop( q );
> > =20
>=20
>=20
>=20

Re: [Cgdb-devel] CGDB Development Methods (was Re: CGDB 1.0 Proposal)

[Bob R. <bo...@br...>]

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

Re: [Cgdb-devel] [ 790050 ] segfault in filedlg - patch

[Bob R. <bo...@br...>]

Hi Bartosz,

Thanks for the patch. I have reproduced the problem you are seeing.
I think you are right about saying the patch belongs in TGDB. I will
look into fixing TGDB so that it returns TGDB_SOURCES_DENIED the
first time, and not just every time after the first time.

Also, because of this bug, I found another bug that needs to be fixed.
The second time, when you actually do get the message
"...No sources available...", you have to hit ESC or 'q' to get out of
the file dialog mode, before you can hit any other keys ( CGDB thinks it
is in the filedlg ). If the error occurs, I think it should leave you in
CGDB's window.

So, I'll try to fix these 2 bugs today.

By the way, are you working with Robert Lemmen? I know he has done some
work for packing CGDB with debian. I don't know exactly what he did, but
I know he worked on it a little. His Email is rob...@se... if
you want to find out what he is doing.

Thanks for the heads up,
Bob Rossi


On Tue, Aug 19, 2003 at 09:36:56PM +0200, Bartosz Zapalowski wrote:
> Hi
>=20
> Here's a patch that solves the bug #790050.
>=20
> I plan to package cgdb for Debian and have this package sponsored.
> Because of that you can expect more patches from me, because I want no
> bugs in programs I package, got it ;).
>=20
> This patch is rather a quick hack, and not the proper solution. However,
> the source code is hard do hack, hence this workaround.
>=20
> The proper fix would be to patch tgdb sources. Try the following
> *before* applying this patch:
> $ cgdb
> ESC, o
> q
> ESC, o
>=20
> As you can see, at first you get a blank screen. At a second 'o' command
> you get
> Error: No sources available! Was program compiled with debug?
>=20
> As I figured out, the problem is in annotate-two, which incorrectly
> parses gdb output for the first time (or maybe it's gdb bad boy?).
>=20
> --=20
> Bartosz Zapalowski
> ba...@kl...

> diff -ruN cgdb-0.3.4-old/cgdb/src/cgdb.c cgdb-0.3.4-new/cgdb/src/cgdb.c
> --- cgdb-0.3.4-old/cgdb/src/cgdb.c	2003-06-24 03:25:35.000000000 +0200
> +++ cgdb-0.3.4-new/cgdb/src/cgdb.c	2003-08-19 21:15:10.000000000 +0200
> @@ -366,6 +366,12 @@
> =20
>                  if_clear_filedlg();
> =20
> +		if (queue_size (q) =3D=3D 0) {
> +    		    if_display_message("Error:", 0, =20
> +     			" No sources available! Was program compiled with debug?");
> +		    break;
> +		}
> +
>                  while ( queue_size ( q ) > 0 ) {
>                      s =3D queue_pop( q );
> =20

[Cgdb-devel] [ 790050 ] segfault in filedlg - patch

[Bartosz Z. <ba...@kl...>]

Hi

Here's a patch that solves the bug #790050.

I plan to package cgdb for Debian and have this package sponsored.
Because of that you can expect more patches from me, because I want no
bugs in programs I package, got it ;).

This patch is rather a quick hack, and not the proper solution. However,
the source code is hard do hack, hence this workaround.

The proper fix would be to patch tgdb sources. Try the following
*before* applying this patch:
$ cgdb
ESC, o
q
ESC, o

As you can see, at first you get a blank screen. At a second 'o' command
you get
Error: No sources available! Was program compiled with debug?

As I figured out, the problem is in annotate-two, which incorrectly
parses gdb output for the first time (or maybe it's gdb bad boy?).

-- 
Bartosz Zapalowski
ba...@kl...

Re: [Cgdb-devel] source windows for 1.0 proposal

[Mike M. <mmu...@cs...>]

Whoa, that's a really cool idea!

I think we should definitely consider supporting that if it's easy 
enough for 1.0.

Mike

On Sat, 16 Aug 2003, Bob Rossi wrote:

:Hi,
:
:I was just thinking about how 1.0 would work. I was thinking about the
:different source windows the user would be able to work with. Then I
:realized that gdb supports debugging multiple threads. We should probably
:be able to lock a window onto a specific thread. That would be pretty
:helpful!
:
:Anyways, I don't even know if MI supports what I am thinking. I will
:look into it. Any suggestions? Is this a 1.0 feature or not ( 2.0 ) ?
:If its not a 1.0 feature, 1.0 should probably at least be designed in
:such a way that adding the feature after would be trivial.
:
:Thanks,
:Bob Rossi
:

[Cgdb-devel] source windows for 1.0 proposal

[Bob R. <bo...@br...>]

Hi,

I was just thinking about how 1.0 would work. I was thinking about the
different source windows the user would be able to work with. Then I
realized that gdb supports debugging multiple threads. We should probably
be able to lock a window onto a specific thread. That would be pretty
helpful!

Anyways, I don't even know if MI supports what I am thinking. I will
look into it. Any suggestions? Is this a 1.0 feature or not ( 2.0 ) ?
If its not a 1.0 feature, 1.0 should probably at least be designed in
such a way that adding the feature after would be trivial.

Thanks,
Bob Rossi

Re: [Cgdb-devel] CGDB Development Methods (was Re: CGDB 1.0 Proposal)

[Mike M. <mmu...@cs...>]

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

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

Re: [Cgdb-devel] CGDB 1.0 Proposal

[Bob R. <bo...@br...>]

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

[Cgdb-devel] CGDB 1.0 Proposal

[Mike M. <mmu...@cs...>]

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

[Cgdb-devel] cgdb release candidate

[Bob R. <bo...@br...>]

Hi,

The current cvs version of cgdb is a release candidate for cgdb-0.3.4.
Feel free to try it out and make sure it is working properly. If I or
anyone else do not find a bug within a few days, it will be released.

Thanks,
Bob Rossi

[Cgdb-devel] GNU readline

[Bob R. <bo...@br...>]

Hi,

I personally feel that the GNU readline library is not working well with
CGDB. We should consider re-writing a similar library, that does what we
need it to do. This way, we won't have a 1:1 correlation between
readline contexts and process forks.=20

If we can find a good readline clone, that could be fine also.
We could also try to modify the readline sources ....
Any ideas?

Bob Rossi

Re: [Cgdb-devel] cgdb and assembly

[Mike M. <mmu...@cs...>]

On Wed, 30 Jul 2003, Peter Kovacs wrote:

:I'm not sure that its all entirely necessary, although I definitely like
:the idea of the multiple source view windows.

The point is generality.  If we have the ability to set a window to 
any mode (source, asm, mixed), then the user has the most freedom.  
He could have a source window and an asm window going at the same 
time, or he could use one window with the mixed view, or do other 
combinations that we're not even considering right now.  The way 
we're looking at it is why impose limitations?

:So, first of all, I think that we should have Source and Mixed Assembly.
:I personally think that's the most useful view.  When you're in Mixed,
:next implicitly means 'nexti' (next instruction).

That's an interesting point.  Since we don't really have 'next' 
shortcuts anymore, I don't think it's applicable though.  We don't 
really want to intercept the user's typed commands to gdb, that is 
too nasty.  It does raise the issue of whether we should reintroduce 
the shortcuts, maybe through :commands.

:I'll have to think about the multiple source views problem.  I'm
:thinking some sort of event system, however I'm not sure that would be
:the best thing to bundle into libtgdb which we eventually hope to be
:used by other parties.  The idea would be that tgdb would output
:different types of events like 'view source' events or 'terminal
:output'.  cgdb would be responsible for catching these events, and
:distributing them to the right places.  Seems a tad overly complicated,
:but it might be a step in the right direction.
:
:Another idea would be to register a series of callback functions.  So
:when you create a source view, you register with tgdb and get called
:whenever there is a source view update.  The problem with this, (and
:with the event based approach) is how do you handle source file changes.
:Do you wipe out all the windows?  Do you refresh all the windows with
:the new source file?

Bob & I were thinking of using a callback system for this, I 
believe.  The event system is tough because the main loop for a UI 
is always going to be a select() loop.  To have an event-driven 
system means we'd have to somehow get the UI out of the select loop 
so that we can call event-handling functions.  It seems simpler to 
just use callbacks.

:
:- Peter

Mike