Re: [Cgdb-devel] TGDB return structures

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

Woooo, I really like that idea. Thanks Peter. I'll go down that path and
see what it yields!

Bob Rossi

On Mon, Sep 15, 2003 at 09:03:13AM -0400, Peter Kovacs wrote:
> If the problem is, retreiving a list of actions/info from tgdb, why not
> just call a function in a loop until it returns NULL?  (Or something
> like that).
>=20
>     action =3D tgdb_first_action( tgdb );
>     do=20
>     {
>         ... /* process action */
>     }
>     while( action =3D tgdb_next_action( tgdb, action ) );
>=20
> You might be able to keep the queue struct in the tgdb side of things,
> and only export the parts that are needed for the action side.
>=20
> Does that even make sense?  Its early, and I'm home sick. :(
>=20
> - Peter
>=20
> On Sun, Sep 14, 2003 at 09:07:22PM -0400, Bob Rossi wrote:
> > Hi All,
> >=20
> > I am struggling with a particular issue. I feel that this issue is
> > *really* important to the future of TGDB and I can not come up with a
> > reasonable solution.
> >=20
> > Currently, TGDB only returns
> > data to the front end as a return value of the function
> > tgdb_recv_debugger_data. The prototype is below.
> >=20
> > size_t tgdb_recv_debugger_data ( struct tgdb *tgdb, char *buf, size_t n,
> > struct queue *q );
> >=20
> > The return value q, is basically a list of commands that TGDB has
> > discovered from parsing the output of GDB. Stuff like TGDB_BREAKPOINTS,
> > ...
> >=20
> > The problem is, I don't want to export the 'struct queue' data structure
> > because its a ridiculous data structure to 'show the world'. I don't
> > really want front end writers to have to learn how to use the silly data
> > structure. The struct was invented to be used for TGDB's internal, it
> > only was exported to the front end to save time.
> >=20
> > What do you guys think a good way of returning commands to the front en=
d is?
> >=20
> >  1. callbacks=20
> >     This isn't really that much different, except I could call function=
s that=20
> >     take a specific data structure like ( struct tgdb_breakpoint ).
> >     The downside is that the client will have to register a lot of
> >     callbacks, and some GUI's don't fit the callback method well.
> >     Especially with multiple contexts.
> >=20
> >     I don't really like this alternative. It seems like some GUI's won't
> >     fit this model well without modifing TGDB.
> >=20
> >  2. keep the data structure in the return value.
> >     I will need to get a 'real' data structure like glib's glist or
> >     something.
> >=20
> >     I don't really like this alternative either :)
> >=20
> > Well, what do you guys think, any ideas?
> >=20
> > Bob Rossi
>=20
>=20
>=20
> --=20
> Peter D. Kovacs <pe...@ko...>