Thread: [Cgdb-devel] New libraries for CGDB
Brought to you by:
bobbybrasko,
crouchingturbo
Menu
▾
▴
cgdb-devel
|
From: Bob R. <bo...@br...> - 2004-02-27 06:33:29
|
Hi, It's been a long time. However, some of the developers of CGDB are ready to start another round of development, which will make CGDB's interface much more VI compatible. There will be several new libraries created to ease the task of implementing CGDB. libkui will be one of them. This stands for "key user interface". It will be the library responsible for catching user commands. For example, when you hit "5Control-wj" in vim, you expect vim to move you down 5 windows. Well, libkui will be responsible for getting these sequences and returning what command the user requested. There will be several other libraries created and talked about in the near future. I am proposing we place all of the new libraries in cgdb/lib. This will be a new directory. Each library will get a directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these directories will have a src/ and inc/ which implements the library. So, for libkui I will add cgdb/lib cgdb/lib/kui cgdb/lib/kui/inc cgdb/lib/kui/src Does everyone think this is reasonable? If so, I'll add this infrastructure to the CGDB CVS tree. Thanks, Bob Rossi |
|
From: Mike M. <mmu...@cs...> - 2004-02-27 14:06:37
|
> There will be several other libraries created and talked about in the > near future. I am proposing we place all of the new libraries in > cgdb/lib. This will be a new directory. Each library will get a > directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these > directories will have a src/ and inc/ which implements the library. So, > for libkui I will add > cgdb/lib > cgdb/lib/kui > cgdb/lib/kui/inc > cgdb/lib/kui/src > > Does everyone think this is reasonable? If so, I'll add this > infrastructure to the CGDB CVS tree. Sounds perfect to me. Mike |
|
From: Robert L. <rob...@se...> - 2004-02-27 15:30:08
|
On Fri, Feb 27, 2004 at 12:03:19AM -0500, Bob Rossi wrote: > It's been a long time. However, some of the developers of CGDB are ready > to start another round of development, which will make CGDB's interface > much more VI compatible. sounds cool to me, everything should be more vi compatible! on a side note: gereal usability of cgdb would probably increase most not by changes to the code but by adding more documentation ;) cu robert --=20 Robert Lemmen http://www.semistable.com=20 |
|
From: Mike M. <mmu...@cs...> - 2004-02-27 15:47:34
|
> on a side note: gereal usability of cgdb would probably increase most > not by changes to the code but by adding more documentation ;) We all agree on this point. The point of reworking CGDB now is because the current design prohibits us from doing things we'd like to do with it= . One of those things is an integrated help system (:help). Another is emulating vi's behavior to a high degree (which we believe will improve usability, because most of our users are already vi users). Mike |
|
From: Bob R. <bo...@br...> - 2004-02-27 16:05:41
|
On Fri, Feb 27, 2004 at 10:37:03AM -0500, Mike Mueller wrote: > > on a side note: gereal usability of cgdb would probably increase most > > not by changes to the code but by adding more documentation ;) >=20 > We all agree on this point. The point of reworking CGDB now is because > the current design prohibits us from doing things we'd like to do with it. > One of those things is an integrated help system (:help). Another is > emulating vi's behavior to a high degree (which we believe will improve > usability, because most of our users are already vi users). Good point Robert. I also agree. One of the goals for CGDB 1.0 would be to have a fully functional help system that can be in html,info and man format. As well as integrated into CGDBs soon to be :help functionality. Bob Rossi |
|
From: Ronald Landheer-C. <ro...@la...> - 2004-03-01 14:16:47
|
Bob Rossi wrote: >Hi, > >It's been a long time. However, some of the developers of CGDB are ready >to start another round of development, which will make CGDB's interface >much more VI compatible. > >There will be several new libraries created to ease the task of >implementing CGDB. libkui will be one of them. This stands for "key user >interface". It will be the library responsible for catching user >commands. For example, when you hit "5Control-wj" in vim, you expect vim >to move you down 5 windows. Well, libkui will be responsible for getting >these sequences and returning what command the user requested. > >There will be several other libraries created and talked about in the >near future. I am proposing we place all of the new libraries in >cgdb/lib. This will be a new directory. Each library will get a >directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these >directories will have a src/ and inc/ which implements the library. So, >for libkui I will add > cgdb/lib > cgdb/lib/kui > cgdb/lib/kui/inc > cgdb/lib/kui/src > >Does everyone think this is reasonable? If so, I'll add this >infrastructure to the CGDB CVS tree. > > Seems reasonable enough to me, but for the time being, I'll keep to porting. However, one thing that may be of interest for cgdb is the container library I wrote for Jail-ust (also on SourceForge) which I think will respond to the needs for a hashing implementation discussed here earlier. If you check it out like this: $ export CVSROOT=:pserver:an...@cv...:/cvsroot/jail-ust $ cvs login anoncvs $ cvs co release-libcontain you'll get the current version with all of its dependencies (libreplace and the architecture-dependent code) The included hash implementation comes from the libhash library I wrote for other applications, all my own work (so there are no licensing worries). Everything is available under GPL (unless I say otherwise in writing, in which case the BSD license applies). Th hash implementation is the part of the library that has been tested most, the rest is alpha-quality (the hash has already been used in production software) Just thought this could interest you :) As I am the author of the library, I will of course be happy to support it for CGDB. rlc |
|
From: Bob R. <bo...@br...> - 2004-03-02 23:49:53
|
On Mon, Mar 01, 2004 at 02:42:33PM +0100, Ronald Landheer-Cieslak wrote: > Bob Rossi wrote: >=20 > >Hi, > > > >It's been a long time. However, some of the developers of CGDB are ready > >to start another round of development, which will make CGDB's interface > >much more VI compatible. > > > >There will be several new libraries created to ease the task of > >implementing CGDB. libkui will be one of them. This stands for "key user > >interface". It will be the library responsible for catching user > >commands. For example, when you hit "5Control-wj" in vim, you expect vim > >to move you down 5 windows. Well, libkui will be responsible for getting > >these sequences and returning what command the user requested. > > > >There will be several other libraries created and talked about in the > >near future. I am proposing we place all of the new libraries in > >cgdb/lib. This will be a new directory. Each library will get a > >directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these > >directories will have a src/ and inc/ which implements the library. So, > >for libkui I will add > > cgdb/lib > > cgdb/lib/kui > > cgdb/lib/kui/inc > > cgdb/lib/kui/src > > > >Does everyone think this is reasonable? If so, I'll add this > >infrastructure to the CGDB CVS tree. > >=20 > > > Seems reasonable enough to me, but for the time being, I'll keep to porti= ng. > However, one thing that may be of interest for cgdb is the container=20 > library I wrote for Jail-ust (also on SourceForge) which I think will=20 > respond to the needs for a hashing implementation discussed here earlier. > If you check it out like this: > $ export CVSROOT=3D:pserver:an...@cv...:/cvsroot/jail-ust > $ cvs login > anoncvs > $ cvs co release-libcontain > you'll get the current version with all of its dependencies (libreplace= =20 > and the architecture-dependent code) Sorry for the long delay. This sounds interesting. Unfortunately, it was written in C++ and cgdb is written only in C. The reason CGDB is written in C is because we believe it should be able to port anywhere that GDB does. This way, it can be used in all the same environments. Thanks, Bob Rossi |
|
From: Bob R. <bo...@br...> - 2004-03-03 03:23:17
|
> > Seems reasonable enough to me, but for the time being, I'll keep to por= ting. > > However, one thing that may be of interest for cgdb is the container=20 > > library I wrote for Jail-ust (also on SourceForge) which I think will= =20 > > respond to the needs for a hashing implementation discussed here earlie= r. > > If you check it out like this: > > $ export CVSROOT=3D:pserver:an...@cv...:/cvsroot/jail-u= st > > $ cvs login > > anoncvs > > $ cvs co release-libcontain > > you'll get the current version with all of its dependencies (libreplace= =20 > > and the architecture-dependent code) >=20 > This sounds interesting. Unfortunately, it was written in C++ and cgdb is > written only in C. The reason CGDB is written in C is because we believe > it should be able to port anywhere that GDB does. This way, it can be > used in all the same environments. As I am starting to think about the implementation of libkui, I am running into walls. It looks like CGDB is going to need some basic C data structures. It is probably unreasonable to think CGDB won't need basic data structures like linked lists, hash tables, ... So, we have 2 options. Use a C library someone else has already written and tested, or go through the pain of writing our own, and making a new project, libadt ( or something ). I would really like to know what everyone thinks we should do here. What does everyone think? Do any of the distro maintainers know of a good portable C library that provides data structures? Thanks, Bob Rossi |
|
From: Peter K. <pe...@ko...> - 2004-03-03 14:35:15
|
On Tue, Mar 02, 2004 at 10:10:01PM -0500, Bob Rossi wrote: > As I am starting to think about the implementation of libkui, I am > running into walls. It looks like CGDB is going to need some basic C > data structures. It is probably unreasonable to think CGDB won't need > basic data structures like linked lists, hash tables, ... >=20 > So, we have 2 options. Use a C library someone else has already written > and tested, or go through the pain of writing our own, and making a new > project, libadt ( or something ). I would really like to know what > everyone thinks we should do here. I would suggest you don't make yet another library. glib has all those data structures you want, and I'm sure there are more just like it. I really don't think we need to waste our time, writing, debugging, and testing another adt library. - Peter --=20 Peter D. Kovacs <pe...@ko...> |
|
From: Bob R. <bo...@br...> - 2004-03-03 15:01:28
|
On Wed, Mar 03, 2004 at 09:21:47AM -0500, Peter Kovacs wrote: > On Tue, Mar 02, 2004 at 10:10:01PM -0500, Bob Rossi wrote: > > As I am starting to think about the implementation of libkui, I am > > running into walls. It looks like CGDB is going to need some basic C > > data structures. It is probably unreasonable to think CGDB won't need > > basic data structures like linked lists, hash tables, ... > >=20 > > So, we have 2 options. Use a C library someone else has already written > > and tested, or go through the pain of writing our own, and making a new > > project, libadt ( or something ). I would really like to know what > > everyone thinks we should do here. >=20 > I would suggest you don't make yet another library. glib has all those > data structures you want, and I'm sure there are more just like it. I > really don't think we need to waste our time, writing, debugging, and > testing another adt library. Ok, it seems like we are interested in the glib data structures. At one point, I believe Ronald said that the library didn't port to Cygwin. I propose that we "rip out" the code we need from Glib. This will get us a minimal implementation of the functions necessary. Then when we think we need to update, I'll merge in the newest version.=20 I'll look into how coupled the ADT's in Glib are to other part's of Glib that we are not interested in. Hopefully if we just get these data structures, there will be nothing to port ( no OS related code ). Thanks, Bob Rossi |
|
From: Ronald Landheer-C. <ro...@la...> - 2004-03-04 15:20:27
|
Bob Rossi wrote: >On Wed, Mar 03, 2004 at 09:21:47AM -0500, Peter Kovacs wrote: > > >>On Tue, Mar 02, 2004 at 10:10:01PM -0500, Bob Rossi wrote: >> >> >>>As I am starting to think about the implementation of libkui, I am >>>running into walls. It looks like CGDB is going to need some basic C >>>data structures. It is probably unreasonable to think CGDB won't need >>>basic data structures like linked lists, hash tables, ... >>> >>>So, we have 2 options. Use a C library someone else has already written >>>and tested, or go through the pain of writing our own, and making a new >>>project, libadt ( or something ). I would really like to know what >>>everyone thinks we should do here. >>> >>> >>I would suggest you don't make yet another library. glib has all those >>data structures you want, and I'm sure there are more just like it. I >>really don't think we need to waste our time, writing, debugging, and >>testing another adt library. >> >> > >Ok, it seems like we are interested in the glib data structures. At one >point, I believe Ronald said that the library didn't port to Cygwin. I >propose that we "rip out" the code we need from Glib. This will get us a >minimal implementation of the functions necessary. Then when we think we >need to update, I'll merge in the newest version. > >I'll look into how coupled the ADT's in Glib are to other part's of Glib >that we are not interested in. Hopefully if we just get these data >structures, there will be nothing to port ( no OS related code ). > > There currently is no glib port for Cygwin - that doesn't necessarily mean that it can't be ported. Perhaps it already has been ported as part of the Cygwin-GNOME (or GNOME-Cygwin - I forget) project, but I don't know that. What I would personally like to avoid is external dependencies on code that is out of "our" control, which would make it more difficult for porters (such as myself) to get the necessary patches upstream. (In any case, glib does not build OOTB (on an OOTB Cygwin install) and apparently has some external dependencies of its own). Again, for the data structures you want, I need the same ones for the Jail-ust project and am writing equivalents of what I wrote in C++ in C. The interface of the hash implementation won't change when I write it in C (there will just be a new type added and the C++ code will be put in defines to handle the absence of a C++ compiler (or the absence of interest in the C++ parts). I'm willing to bump the priority - I have a few weeks of programming time on my hands anyway - and I would personally be very interested in having a somewhat larger userbase than that of Jail-ust for this library - mostly because Jail-ust is a nascent project with no users at this time except for its components. Just me two cents :) rlc |
|
From: Bob R. <bo...@br...> - 2004-03-04 21:26:18
|
On Thu, Mar 04, 2004 at 02:59:21PM +0100, Ronald Landheer-Cieslak wrote: > >Ok, it seems like we are interested in the glib data structures. At one > >point, I believe Ronald said that the library didn't port to Cygwin. I > >propose that we "rip out" the code we need from Glib. This will get us a > >minimal implementation of the functions necessary. Then when we think we > >need to update, I'll merge in the newest version.=20 > > > >I'll look into how coupled the ADT's in Glib are to other part's of Glib > >that we are not interested in. Hopefully if we just get these data > >structures, there will be nothing to port ( no OS related code ). > >=20 > > > Again, for the data structures you want, I need the same ones for the=20 > Jail-ust project and am writing equivalents of what I wrote in C++ in C.= =20 > The interface of the hash implementation won't change when I write it in= =20 > C (there will just be a new type added and the C++ code will be put in=20 > defines to handle the absence of a C++ > compiler (or the absence of interest in the C++ parts). >=20 > I'm willing to bump the priority - I have a few weeks of programming=20 > time on my hands anyway - and I would personally be very interested in=20 > having a somewhat larger userbase than that of Jail-ust for this library= =20 > - mostly because Jail-ust is a nascent project with no users at this=20 > time except for its components. I think we have decided to make a C standard library deal for CGDB. I am going to port the ones from Glib over to not depend on Glib anymore. They are well tested and already come with testcases. I already ported Glist and Ghash and it took me only about an hour or so. The reason behind doing this is that I can get the ADT's now, and they have already been field tested and come with test cases. If you would like to add some ADT's to the library that CGDB could use in the long run, that would be cool. I feel like, when CGDB is done, we could probably allow other projects to use the ADT library base. Thanks, Bob Rossi |
|
From: Ronald Landheer-C. <ro...@la...> - 2004-03-04 15:20:26
|
Bob Rossi wrote: >On Mon, Mar 01, 2004 at 02:42:33PM +0100, Ronald Landheer-Cieslak wrote: > > >>Bob Rossi wrote: >> >> >> >>>Hi, >>> >>>It's been a long time. However, some of the developers of CGDB are ready >>>to start another round of development, which will make CGDB's interface >>>much more VI compatible. >>> >>>There will be several new libraries created to ease the task of >>>implementing CGDB. libkui will be one of them. This stands for "key user >>>interface". It will be the library responsible for catching user >>>commands. For example, when you hit "5Control-wj" in vim, you expect vim >>>to move you down 5 windows. Well, libkui will be responsible for getting >>>these sequences and returning what command the user requested. >>> >>>There will be several other libraries created and talked about in the >>>near future. I am proposing we place all of the new libraries in >>>cgdb/lib. This will be a new directory. Each library will get a >>>directory in cgdb/lib. For example cgdb/lib/kui. Finally, each of these >>>directories will have a src/ and inc/ which implements the library. So, >>>for libkui I will add >>> cgdb/lib >>> cgdb/lib/kui >>> cgdb/lib/kui/inc >>> cgdb/lib/kui/src >>> >>>Does everyone think this is reasonable? If so, I'll add this >>>infrastructure to the CGDB CVS tree. >>> >>> >>> >>> >>Seems reasonable enough to me, but for the time being, I'll keep to porting. >>However, one thing that may be of interest for cgdb is the container >>library I wrote for Jail-ust (also on SourceForge) which I think will >>respond to the needs for a hashing implementation discussed here earlier. >>If you check it out like this: >>$ export CVSROOT=:pserver:an...@cv...:/cvsroot/jail-ust >>$ cvs login >>anoncvs >>$ cvs co release-libcontain >>you'll get the current version with all of its dependencies (libreplace >>and the architecture-dependent code) >> >> > >Sorry for the long delay. > >This sounds interesting. Unfortunately, it was written in C++ and cgdb is >written only in C. The reason CGDB is written in C is because we believe >it should be able to port anywhere that GDB does. This way, it can be >used in all the same environments. > >Thanks, >Bob Rossi > > A hash implementation in C is under development. The only part actually written in C++ is the hash implementation - other parts of the library are written in C only. If you want, I can bump the priority of a C-only implementation of the hash on my list of things to do. (See also my next mail) rlc |
×
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