cgdb-devel

[Cgdb-devel] TGDB structures

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

Hi,

I was seriously thinking about making TGDB depend on Glib.
What do you guys think?

This is really important since we would be exporting lists of type Glist
to the front ends? Are there any objections? Or better solutions?

Bob Rossi

Re: [Cgdb-devel] TGDB structures

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

On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
> I was seriously thinking about making TGDB depend on Glib.
> What do you guys think?
> 
> This is really important since we would be exporting lists of type Glist
> to the front ends? Are there any objections? Or better solutions?
IMHO, that would not be a good idea. You'd loose portability for some of 
the platforms cgdb currently works under (including Cygwin, as glib is not
part of the Cygwin distribution).

You could, of course, make the dependency optional, but the problem with 
optional dependencies is that they tend to become maintenance nightmares
rather quickly.

Personally, I'd probably opt for making a light-weight list implementation
if you really need one for tgdb. Lists are not that hard to implement 
efficiently.

Just my opinion, of course, but I would like to avoid cgdb depending on 
anything not in the Cygwin distribution, as it would make it a bit harder 
to maintain a cgdb version for Cygwin :|

rlc

-- 
Television has proved that people will look at anything rather than each other.
		-- Ann Landers

Re: [Cgdb-devel] TGDB structures

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

Ok, well then that settles it. We will not use glib for TGDB. I will
write up a quick implementation of 'struct tgdb_list'. Then I will
export that to the front end side. So, all front end writers will have
to manipulate tgdb_list structures.

If anyone can think of anything better, let me know.

Hey Peter, do you still like the idea of 'tgdb_get_command()' even
though we have the list implementation now? I could just return a
tgdb_list of commands. For some strange reason, I still kind of like the
tgdb_get_command() function. It avoids the list of list problem. If
that can be called a problem.

A list of commands. Where each command can have a list of breakpoints,
or a list of frames ...

Sometimes I am not sure if these little details even matter :)

Bob Rossi

On Wed, Sep 17, 2003 at 12:31:16PM +0200, Ronald Landheer-Cieslak wrote:
> On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
> > I was seriously thinking about making TGDB depend on Glib.
> > What do you guys think?
> >=20
> > This is really important since we would be exporting lists of type Glist
> > to the front ends? Are there any objections? Or better solutions?
> IMHO, that would not be a good idea. You'd loose portability for some of=
=20
> the platforms cgdb currently works under (including Cygwin, as glib is not
> part of the Cygwin distribution).
>=20
> You could, of course, make the dependency optional, but the problem with=
=20
> optional dependencies is that they tend to become maintenance nightmares
> rather quickly.
>=20
> Personally, I'd probably opt for making a light-weight list implementation
> if you really need one for tgdb. Lists are not that hard to implement=20
> efficiently.
>=20
> Just my opinion, of course, but I would like to avoid cgdb depending on=
=20
> anything not in the Cygwin distribution, as it would make it a bit harder=
=20
> to maintain a cgdb version for Cygwin :|
>=20
> rlc
>=20
> --=20
> Television has proved that people will look at anything rather than each =
other.
> 		-- Ann Landers
>=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] TGDB structures

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

While having a generic list package is helpful, its pretty easy to make
a linked list, just by sticking a 'next' pointer at the end of a struct.
I'm just sayin, is all.

You can still do the tgdb_get_command, if you pass an opaque iterator
around.  Check out the Iterator design pattern (in the book, "Design
Patterns").  Personally, I think the less mucking around inside the tgdb
api, the better. =20

- Peter

On Wed, Sep 17, 2003 at 08:27:16AM -0400, Bob Rossi wrote:
> Ok, well then that settles it. We will not use glib for TGDB. I will
> write up a quick implementation of 'struct tgdb_list'. Then I will
> export that to the front end side. So, all front end writers will have
> to manipulate tgdb_list structures.
>=20
> If anyone can think of anything better, let me know.
>=20
> Hey Peter, do you still like the idea of 'tgdb_get_command()' even
> though we have the list implementation now? I could just return a
> tgdb_list of commands. For some strange reason, I still kind of like the
> tgdb_get_command() function. It avoids the list of list problem. If
> that can be called a problem.
>=20
> A list of commands. Where each command can have a list of breakpoints,
> or a list of frames ...
>=20
> Sometimes I am not sure if these little details even matter :)
>=20
> Bob Rossi
>=20
> On Wed, Sep 17, 2003 at 12:31:16PM +0200, Ronald Landheer-Cieslak wrote:
> > On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
> > > I was seriously thinking about making TGDB depend on Glib.
> > > What do you guys think?
> > >=20
> > > This is really important since we would be exporting lists of type Gl=
ist
> > > to the front ends? Are there any objections? Or better solutions?
> > IMHO, that would not be a good idea. You'd loose portability for some o=
f=20
> > the platforms cgdb currently works under (including Cygwin, as glib is =
not
> > part of the Cygwin distribution).
> >=20
> > You could, of course, make the dependency optional, but the problem wit=
h=20
> > optional dependencies is that they tend to become maintenance nightmares
> > rather quickly.
> >=20
> > Personally, I'd probably opt for making a light-weight list implementat=
ion
> > if you really need one for tgdb. Lists are not that hard to implement=
=20
> > efficiently.
> >=20
> > Just my opinion, of course, but I would like to avoid cgdb depending on=
=20
> > anything not in the Cygwin distribution, as it would make it a bit hard=
er=20
> > to maintain a cgdb version for Cygwin :|
> >=20
> > rlc
> >=20
> > --=20
> > Television has proved that people will look at anything rather than eac=
h other.
> > 		-- Ann Landers
> >=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
Peter D. Kovacs <pe...@ko...>

Re: [Cgdb-devel] TGDB structures

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

On Wed, 17 Sep 2003, Peter Kovacs wrote:

:While having a generic list package is helpful, its pretty easy to make
:a linked list, just by sticking a 'next' pointer at the end of a struct.
:I'm just sayin, is all.

The point of this exercise was that a 'next' pointer in a struct is 
not a very abstract way to make a list.  I'm not a fan of having to 
mess with pointers every time you want to manipulate a list.  I 
think if we do make a list type, it should have a set of functions 
that operates on it and makes it reliable.

:You can still do the tgdb_get_command, if you pass an opaque iterator
:around.  Check out the Iterator design pattern (in the book, "Design
:Patterns").  Personally, I think the less mucking around inside the tgdb
:api, the better.  

The iterator isn't needed, the TGDB context will handle it.

:- Peter

Mike

:On Wed, Sep 17, 2003 at 08:27:16AM -0400, Bob Rossi wrote:
:> Ok, well then that settles it. We will not use glib for TGDB. I will
:> write up a quick implementation of 'struct tgdb_list'. Then I will
:> export that to the front end side. So, all front end writers will have
:> to manipulate tgdb_list structures.
:> 
:> If anyone can think of anything better, let me know.
:> 
:> Hey Peter, do you still like the idea of 'tgdb_get_command()' even
:> though we have the list implementation now? I could just return a
:> tgdb_list of commands. For some strange reason, I still kind of like the
:> tgdb_get_command() function. It avoids the list of list problem. If
:> that can be called a problem.
:> 
:> A list of commands. Where each command can have a list of breakpoints,
:> or a list of frames ...
:> 
:> Sometimes I am not sure if these little details even matter :)
:> 
:> Bob Rossi
:> 
:> On Wed, Sep 17, 2003 at 12:31:16PM +0200, Ronald Landheer-Cieslak wrote:
:> > On Tue, Sep 16, 2003 at 06:30:32PM -0400, Bob Rossi wrote:
:> > > I was seriously thinking about making TGDB depend on Glib.
:> > > What do you guys think?
:> > > 
:> > > This is really important since we would be exporting lists of type Glist
:> > > to the front ends? Are there any objections? Or better solutions?
:> > IMHO, that would not be a good idea. You'd loose portability for some of 
:> > the platforms cgdb currently works under (including Cygwin, as glib is not
:> > part of the Cygwin distribution).
:> > 
:> > You could, of course, make the dependency optional, but the problem with 
:> > optional dependencies is that they tend to become maintenance nightmares
:> > rather quickly.
:> > 
:> > Personally, I'd probably opt for making a light-weight list implementation
:> > if you really need one for tgdb. Lists are not that hard to implement 
:> > efficiently.
:> > 
:> > Just my opinion, of course, but I would like to avoid cgdb depending on 
:> > anything not in the Cygwin distribution, as it would make it a bit harder 
:> > to maintain a cgdb version for Cygwin :|
:> > 
:> > rlc
:> > 
:> > -- 
:> > Television has proved that people will look at anything rather than each other.
:> > 		-- Ann Landers
:> > 
:> > 
:> > -------------------------------------------------------
:> > 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] TGDB structures

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

On Wed, Sep 17, 2003 at 09:53:06AM -0400, Mike Mueller wrote:
> On Wed, 17 Sep 2003, Peter Kovacs wrote:
>=20
> :While having a generic list package is helpful, its pretty easy to make
> :a linked list, just by sticking a 'next' pointer at the end of a struct.
> :I'm just sayin, is all.
>=20
> The point of this exercise was that a 'next' pointer in a struct is=20
> not a very abstract way to make a list.  I'm not a fan of having to=20
> mess with pointers every time you want to manipulate a list.  I=20
> think if we do make a list type, it should have a set of functions=20
> that operates on it and makes it reliable.

Well, it would be easy enough to create a set of macro's to do anything
you wanted.  Heck if you put the next pointer first in the struct, they
could be functions (we all know how much bob hates macros).

I just think its a bit of a waste to go around making generic list
packages when there are already so many of them out there (although
Ronald brings up a good point about dependencies), and its not strictly
necessary.  Sure it might only take a few hours to write, I just don't
see the point.

One benefit of having the next pointer is that when you're manipulating
an element of the list, you don't have to back out to get to the next
element: everything is internalized.

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

Re: [Cgdb-devel] TGDB structures

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

On Wed, Sep 17, 2003 at 10:15:34AM -0400, Peter Kovacs wrote:
> On Wed, Sep 17, 2003 at 09:53:06AM -0400, Mike Mueller wrote:
> > On Wed, 17 Sep 2003, Peter Kovacs wrote:
> > 
> > :While having a generic list package is helpful, its pretty easy to make
> > :a linked list, just by sticking a 'next' pointer at the end of a struct.
> > :I'm just sayin, is all.
> > 
> > The point of this exercise was that a 'next' pointer in a struct is 
> > not a very abstract way to make a list.  I'm not a fan of having to 
> > mess with pointers every time you want to manipulate a list.  I 
> > think if we do make a list type, it should have a set of functions 
> > that operates on it and makes it reliable.
> 
> Well, it would be easy enough to create a set of macro's to do anything
> you wanted.  Heck if you put the next pointer first in the struct, they
> could be functions (we all know how much bob hates macros).
> 
> I just think its a bit of a waste to go around making generic list
> packages when there are already so many of them out there (although
> Ronald brings up a good point about dependencies), and its not strictly
> necessary.  Sure it might only take a few hours to write, I just don't
> see the point.
> 
> One benefit of having the next pointer is that when you're manipulating
> an element of the list, you don't have to back out to get to the next
> element: everything is internalized.
I don't know whether it's a real concern for cgdb, but there is thread-safety
to concern, which makes a good implementation of a list a bit less trivial
than simply maintaining a next pointer - as the actual next pointer may
well change right under your nose..

If thread-safety is not a concern, then I don't see much of a point in 
making a generic API for lists either (though it does tend to become a 
concern later on..)

Still, though it may not be as trivial as having a next pointer in a struct,
it is not very complicated either: a non-blocking way of verifying whether
your pointer is still OK before writing to it is available on all ix86 
platforms since the 486; it's available on the Sparc (though I don't know
since when) and on many other chips. And if a non-blocking way to do it
is not available, a fine-grained blocking implementation can be (almost) just
as fast.

rlc

-- 
A long memory is the most subversive idea in America.

Re: [Cgdb-devel] TGDB structures

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

On Wed, Sep 17, 2003 at 05:06:38PM +0200, Ronald Landheer-Cieslak wrote:
> On Wed, Sep 17, 2003 at 10:15:34AM -0400, Peter Kovacs wrote:
> > On Wed, Sep 17, 2003 at 09:53:06AM -0400, Mike Mueller wrote:
> > > On Wed, 17 Sep 2003, Peter Kovacs wrote:
> > >=20
> > > :While having a generic list package is helpful, its pretty easy to m=
ake
> > > :a linked list, just by sticking a 'next' pointer at the end of a str=
uct.
> > > :I'm just sayin, is all.
> > >=20
> > > The point of this exercise was that a 'next' pointer in a struct is=
=20
> > > not a very abstract way to make a list.  I'm not a fan of having to=
=20
> > > mess with pointers every time you want to manipulate a list.  I=20
> > > think if we do make a list type, it should have a set of functions=20
> > > that operates on it and makes it reliable.
> >=20
> > Well, it would be easy enough to create a set of macro's to do anything
> > you wanted.  Heck if you put the next pointer first in the struct, they
> > could be functions (we all know how much bob hates macros).
> >=20
> > I just think its a bit of a waste to go around making generic list
> > packages when there are already so many of them out there (although
> > Ronald brings up a good point about dependencies), and its not strictly
> > necessary.  Sure it might only take a few hours to write, I just don't
> > see the point.
> >=20
> > One benefit of having the next pointer is that when you're manipulating
> > an element of the list, you don't have to back out to get to the next
> > element: everything is internalized.
> I don't know whether it's a real concern for cgdb, but there is thread-sa=
fety
> to concern, which makes a good implementation of a list a bit less trivial
> than simply maintaining a next pointer - as the actual next pointer may
> well change right under your nose..
>=20
> If thread-safety is not a concern, then I don't see much of a point in=20
> making a generic API for lists either (though it does tend to become a=20
> concern later on..)
>=20
> Still, though it may not be as trivial as having a next pointer in a stru=
ct,
> it is not very complicated either: a non-blocking way of verifying whether
> your pointer is still OK before writing to it is available on all ix86=20
> platforms since the 486; it's available on the Sparc (though I don't know
> since when) and on many other chips. And if a non-blocking way to do it
> is not available, a fine-grained blocking implementation can be (almost) =
just
> as fast.

I think leaving out the possibility of threading could be a mistake.
We should probably at least design TGDB in a way where it is thread
safe capable. Even if it doesn't support multi-threaded applications.
I don't know much about threaded applications, but it seems like Ronald
is stating the an ADT would support threads a little better that a
simple linked list. ( depending on the implementation of the ADT )

Any other considerations?

I really hope to only do this once. As I am tired of going back to
change things that were not well thought out in the first place. The
structures are particularly important because they are really the only
thing that will affect all front ends.

Bob Rossi

Re: [Cgdb-devel] TGDB structures

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

..

> > it is not very complicated either: a non-blocking way of verifying whether
> > your pointer is still OK before writing to it is available on all ix86=20
> > platforms since the 486; it's available on the Sparc (though I don't know
> > since when) and on many other chips. And if a non-blocking way to do it
> > is not available, a fine-grained blocking implementation can be (almost) =
> just
> > as fast.
> 
> I think leaving out the possibility of threading could be a mistake.
> We should probably at least design TGDB in a way where it is thread
> safe capable. Even if it doesn't support multi-threaded applications.
> I don't know much about threaded applications, but it seems like Ronald
> is stating the an ADT would support threads a little better that a
> simple linked list. ( depending on the implementation of the ADT )
> 
> Any other considerations?
> 
> I really hope to only do this once. As I am tired of going back to
> change things that were not well thought out in the first place. The
> structures are particularly important because they are really the only
> thing that will affect all front ends.
> 

8-)
You have to realize you will never get things right the first time,
simply not possible.
My point was to bring this to your attention as you were asking
for feeback.

The MI front end that we did is "Thread-safe" but not "Reentrant".
There is a distinction.  It's thread-safe that you can use
multiple thread and the library will serialize the requests if
need be ore does not carry any state that can make the use of
thread impossible.  It is not "reentrant" meaning that it serialize
commands and trying to recall/reenter a command may mean deadlock.

That sayd, If you say that in version 1.0 of tgdb you folks
will not worry about threads and will tackle the issue only in
2.0 ... that's certainly reasonnable.  Some issues can be
deal better with some later version, when the direction is better understood.

my 0.0002 canadian.

Re: [Cgdb-devel] TGDB structures

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

On Wed, Sep 17, 2003 at 03:25:26PM -0400, Alain Magloire wrote:
> ..
>=20
> > > it is not very complicated either: a non-blocking way of verifying wh=
ether
> > > your pointer is still OK before writing to it is available on all ix8=
6=3D20
> > > platforms since the 486; it's available on the Sparc (though I don't =
know
> > > since when) and on many other chips. And if a non-blocking way to do =
it
> > > is not available, a fine-grained blocking implementation can be (almo=
st) =3D
> > just
> > > as fast.
> >=20
> > I think leaving out the possibility of threading could be a mistake.
> > We should probably at least design TGDB in a way where it is thread
> > safe capable. Even if it doesn't support multi-threaded applications.
> > I don't know much about threaded applications, but it seems like Ronald
> > is stating the an ADT would support threads a little better that a
> > simple linked list. ( depending on the implementation of the ADT )
> >=20
> > Any other considerations?
> >=20
> > I really hope to only do this once. As I am tired of going back to
> > change things that were not well thought out in the first place. The
> > structures are particularly important because they are really the only
> > thing that will affect all front ends.
> >=20
>=20
> 8-)
> You have to realize you will never get things right the first time,
> simply not possible.
> My point was to bring this to your attention as you were asking
> for feeback.
>=20
> The MI front end that we did is "Thread-safe" but not "Reentrant".
> There is a distinction.  It's thread-safe that you can use
> multiple thread and the library will serialize the requests if
> need be ore does not carry any state that can make the use of
> thread impossible.  It is not "reentrant" meaning that it serialize
> commands and trying to recall/reenter a command may mean deadlock.
>=20
> That sayd, If you say that in version 1.0 of tgdb you folks
> will not worry about threads and will tackle the issue only in
> 2.0 ... that's certainly reasonnable.  Some issues can be
> deal better with some later version, when the direction is better underst=
ood.
>=20
> my 0.0002 canadian.

Good point. I think we will worry about threads in 2.0 like you
suggested. However, we will try to write it in a way that is easy to
change to be "Thread-safe" and "Reentrant".

Since there is no front end that relies on this and there is a ton of
other work to do. Like the actual MI integration. :)

Bob Rossi