cgdb-devel Mailing List for the curses debugger (Page 11)
Brought to you by:
bobbybrasko,
crouchingturbo
Menu
▾
▴
cgdb-devel — Development activity -- bug reports, patches, related questions
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(19) |
Mar
(15) |
Apr
(6) |
May
|
Jun
(13) |
Jul
(8) |
Aug
(15) |
Sep
(43) |
Oct
(14) |
Nov
(9) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(4) |
Feb
(9) |
Mar
(15) |
Apr
(5) |
May
(1) |
Jun
|
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(12) |
May
(7) |
Jun
(7) |
Jul
(21) |
Aug
(7) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2006 |
Jan
(3) |
Feb
(2) |
Mar
(5) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
|
Aug
(7) |
Sep
|
Oct
(13) |
Nov
|
Dec
(7) |
| 2007 |
Jan
(3) |
Feb
(16) |
Mar
(6) |
Apr
(8) |
May
(7) |
Jun
(19) |
Jul
(14) |
Aug
(23) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(3) |
Jul
|
Aug
|
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2009 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(11) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(8) |
Dec
(1) |
| 2011 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert L. <rob...@se...> - 2004-07-14 12:33:40
|
On Wed, Jul 14, 2004 at 08:22:41AM -0400, Bob Rossi wrote: > OK, sorry to drag this on, so we think DESTDIR has nothing to do with > the "progs" directory. Do I have to prefix where CGDB get's installed > with it? or does that work fine? right, and the installation otherwise works fine, already uses DESTIDR > So to sum up, we probably don't care about the "progs" directory > for binary distributions. So, DESTDIR doesn't matter with the "progs" > directory, right? So, you suggest using top_bindir. I wonder if > top_builddir is better, because that is guarenteed to be writable. Also, > top_builddir will just put the "progs" directory in the build > directory. However top_bindir will install it into the installation > directory. Is that correct? >=20 > If it is, I would prefer to use top_builddir. If this solves the debian > problem, we can release very soon? sorry, my fault. top_builddir is the way to go. if you want to you could send me a pre-release tarball and i can try the debian installation procedure on it... cu robert --=20 Robert Lemmen http://www.semistable.com=20 |
|
From: Bob R. <bo...@br...> - 2004-07-14 12:23:15
|
On Tue, Jul 13, 2004 at 05:33:00PM +0200, Robert Lemmen wrote: > On Tue, Jul 13, 2004 at 11:19:51AM -0400, Bob Rossi wrote: > > OK, the "progs" directory isn't used for anything by the ordinary user. > > All of the programs created there are driver programs for a subset of > > the functionality of CGDB. I use them to test modules of CGDB, so that > > bugs are easier to track down. We don't need to install them for CGDB to > > work. > > > > What does DESTDIR default to? I just want a place to put the driver > > programs, where would be the least impact place to do this? > > DESTDIR is normally empty, and should prefix installation targets so you > can install to a different place. for example if you are not root on the > machine you could set $DESTDIR to /home/robertle to install into your > home directory. you could do the same by changing $prefix accordingly, > and that is what should happen inside the makefiles. every use of > $prefix or it's derived variables should be used together with $DESTDIR > when installing stuff. > > i think the best place to put the progs if they are internal to the > development process is top_bindir without the usage of $DESTDIR OK, sorry to drag this on, so we think DESTDIR has nothing to do with the "progs" directory. Do I have to prefix where CGDB get's installed with it? or does that work fine? > > My goal for the progs directory is just to have some applications I can > > ask end users to run if CGDB isn't working for them. This allows me to > > find bugs much faster. I don't want to install them on there machine. > > Where would be a good place to put applications of this type? > > hmm, difficult. the problem with binary distributions like debian is > that you either have it on your machine or not. in case of cgdb it's > easier since it is a development tool and you can expect everyone who > uses it to be able to build stuff from source. just put it into > top_bindir when building and we can add a note that says how to build > the stuff in debian if one needs it to track down a bug, ok? So to sum up, we probably don't care about the "progs" directory for binary distributions. So, DESTDIR doesn't matter with the "progs" directory, right? So, you suggest using top_bindir. I wonder if top_builddir is better, because that is guarenteed to be writable. Also, top_builddir will just put the "progs" directory in the build directory. However top_bindir will install it into the installation directory. Is that correct? If it is, I would prefer to use top_builddir. If this solves the debian problem, we can release very soon? Does any of this make sense? Thanks, Bob Rossi |
|
From: SourceForge.net <no...@so...> - 2004-07-14 00:03:04
|
Bugs item #990573, was opened at 2004-07-14 03:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=534974&aid=990573&group_id=72581 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius MUJA (mariusmuja) Assigned to: Nobody/Anonymous (nobody) Summary: Error getting command line arguments Initial Comment: There is a bug in cgdb.c from version 0.4.2 that causes a segfault when getting command line arguments on my computer. The static "struct option long_options[]" vector should have a last element that has to be filled with zeros. I have attached a patch that fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=534974&aid=990573&group_id=72581 |
|
From: Bob R. <bo...@br...> - 2004-07-13 00:58:18
|
On Thu, Jul 01, 2004 at 01:57:48PM +0200, Robert Lemmen wrote: > hi everyone, >=20 > i had a problem with the cgdb build that bites the debian autobuilders. > i patched my way around it, but i think this should be fixed in the long > run >=20 > here we go: the cgdb ./configure supports a DESTDIR with which each > installation path is prefixed. so if you would like to install cgdb in > your home dir because you are not root on a box you could do so. we use > that mechanism in debian to build the packages. cgdb uses a top_srcdir > in most makefiles, which is fine. but it uses that top_srcdir when > installing a "progs" folder and contents. i don't think is's a good idea > to install anything into the source directory, but if then you should > not use DESTDIR with it. anyway, if you want to try this just=20 >=20 > export DESTDIR=3D/tmp > ./configure > make install Thanks for the report Robert. I am trying to do another release, since I have fixed 2 crashes since .4.2, and I have integrated a new key input library, which is way more stable. However, this is the final issue I want to fix before releasing.=20 Since I do not know to much about autoconf, does this patch look OK? It puts the 'progs' directory in the builddir instead of the source dir which makes a lot more sense. However, when I set DESTDIR, I don't think the 'progs' directory get's installed at all and I don't know why. Does anyone care? Is this patch acceptable for your needs? Does anyone else have a better idea? Thanks, Bob Rossi Index: ./cgdb/lib/kui/src/Makefile.am =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/cgdb/lib/kui/src/Makefile.am,v retrieving revision 1.5 diff -w -u -r1.5 Makefile.am --- ./cgdb/lib/kui/src/Makefile.am 20 Apr 2004 23:46:38 -0000 1.5 +++ ./cgdb/lib/kui/src/Makefile.am 13 Jul 2004 00:54:10 -0000 @@ -8,7 +8,7 @@ =20 # Installs the driver programs into progs directory noinst_bin_PROGRAMS =3D kui_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 # This is the kui driver kui_driver_LDFLAGS =3D -L. -L../../../../various/util/src -L../../../../va= rious/adt/src Index: ./cgdb/lib/wm/src/Makefile.am =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/cgdb/lib/wm/src/Makefile.am,v retrieving revision 1.2 diff -w -u -r1.2 Makefile.am --- ./cgdb/lib/wm/src/Makefile.am 6 Jul 2004 04:37:15 -0000 1.2 +++ ./cgdb/lib/wm/src/Makefile.am 13 Jul 2004 00:54:10 -0000 @@ -6,7 +6,7 @@ =20 # Installs the driver programs into progs directory noinst_bin_PROGRAMS =3D wm_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 # This is the wm driver wm_driver_LDFLAGS =3D -L. -L../../../../various/adt/src Index: ./cgdb/tokenizer/src/Makefile.am =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/cgdb/tokenizer/src/Makefile.am,v retrieving revision 1.2 diff -w -u -r1.2 Makefile.am --- ./cgdb/tokenizer/src/Makefile.am 9 Jan 2004 02:03:07 -0000 1.2 +++ ./cgdb/tokenizer/src/Makefile.am 13 Jul 2004 00:54:10 -0000 @@ -13,7 +13,7 @@ =20 # Installs the driver programs into progs directory noinst_bin_PROGRAMS =3D tokenizer_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 # This is the input driver tokenizer_driver_LDFLAGS =3D -L. \ Index: ./tgdb/tgdb-base/src/Makefile.am =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/tgdb-base/src/Makefile.am,v retrieving revision 1.8 diff -w -u -r1.8 Makefile.am --- ./tgdb/tgdb-base/src/Makefile.am 9 Jan 2004 02:03:07 -0000 1.8 +++ ./tgdb/tgdb-base/src/Makefile.am 13 Jul 2004 00:54:10 -0000 @@ -16,7 +16,7 @@ tgdb_client_interface.c =20 noinst_bin_PROGRAMS =3D tgdb_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 tgdb_driver_LDFLAGS =3D \ -L$(top_builddir)/tgdb/tgdb-base/src \ Index: ./various/adt/src/Makefile.am =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/various/adt/src/Makefile.am,v retrieving revision 1.4 diff -w -u -r1.4 Makefile.am --- ./various/adt/src/Makefile.am 16 Mar 2004 21:45:21 -0000 1.4 +++ ./various/adt/src/Makefile.am 13 Jul 2004 00:54:10 -0000 @@ -12,7 +12,7 @@ =20 # Installs the driver programs into progs directory noinst_bin_PROGRAMS =3D std_hash_driver std_list_driver std_tree_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 # This is the input driver std_hash_driver_LDFLAGS =3D -L. Index: ./various/input/src/Makefile.am =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/various/input/src/Makefile.am,v retrieving revision 1.6 diff -w -u -r1.6 Makefile.am --- ./various/input/src/Makefile.am 7 May 2004 12:55:22 -0000 1.6 +++ ./various/input/src/Makefile.am 13 Jul 2004 00:54:11 -0000 @@ -8,7 +8,7 @@ =20 # Installs the driver programs into progs directory noinst_bin_PROGRAMS =3D input_driver getch_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 # This is the input driver input_driver_LDFLAGS =3D -L. -L../../util/src Index: ./various/rlctx/src/Makefile.am =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/various/rlctx/src/Makefile.am,v retrieving revision 1.4 diff -w -u -r1.4 Makefile.am --- ./various/rlctx/src/Makefile.am 9 Jan 2004 02:03:21 -0000 1.4 +++ ./various/rlctx/src/Makefile.am 13 Jul 2004 00:54:11 -0000 @@ -10,7 +10,7 @@ =20 # Installs the driver programs into progs directory noinst_bin_PROGRAMS =3D rlctx_driver -noinst_bindir =3D $(top_srcdir)/progs +noinst_bindir =3D $(top_builddir)/progs =20 # This is the input driver rlctx_driver_LDFLAGS =3D -L. -L../../util/src -L../../rlctx/src -L../../ad= t/src |
|
From: Bob R. <bo...@br...> - 2004-07-01 17:58:20
|
On Thu, Jul 01, 2004 at 01:57:48PM +0200, Robert Lemmen wrote: > hi everyone, >=20 > i had a problem with the cgdb build that bites the debian autobuilders. > i patched my way around it, but i think this should be fixed in the long > run >=20 > here we go: the cgdb ./configure supports a DESTDIR with which each > installation path is prefixed. so if you would like to install cgdb in > your home dir because you are not root on a box you could do so. we use > that mechanism in debian to build the packages. cgdb uses a top_srcdir > in most makefiles, which is fine. but it uses that top_srcdir when > installing a "progs" folder and contents. i don't think is's a good idea > to install anything into the source directory, but if then you should > not use DESTDIR with it. anyway, if you want to try this just=20 >=20 > export DESTDIR=3D/tmp > ./configure > make install Yeah, it should probably write the progs directory to the place were you are building from. I'll try to get some time to figure out how that works. Although with the auto tools, it's always a mystery to me. Thanks, Bob Rossi |
|
From: Robert L. <rob...@se...> - 2004-07-01 11:57:55
|
hi everyone, i had a problem with the cgdb build that bites the debian autobuilders. i patched my way around it, but i think this should be fixed in the long run here we go: the cgdb ./configure supports a DESTDIR with which each installation path is prefixed. so if you would like to install cgdb in your home dir because you are not root on a box you could do so. we use that mechanism in debian to build the packages. cgdb uses a top_srcdir in most makefiles, which is fine. but it uses that top_srcdir when installing a "progs" folder and contents. i don't think is's a good idea to install anything into the source directory, but if then you should not use DESTDIR with it. anyway, if you want to try this just=20 export DESTDIR=3D/tmp =2E/configure make install cu robert --=20 Robert Lemmen http://www.semistable.com=20 |
|
From: <ben...@id...> - 2004-05-22 12:04:19
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Robert L. <rob...@se...> - 2004-04-27 13:17:27
|
On Mon, Apr 26, 2004 at 10:11:28PM -0400, Bob Rossi wrote: > Unfortunatly, it has not been fixed yet. This is because, I need to do > some fundamental error checking/reporting changes that I haven't had > time to do. >=20 > However, if you would like me to just fix that one bug (that case) I can > do that. Does that help on the debian side of things? fix it whenever you have the time, i just need to know and was too lazy to check (quite some setup needed to reproduce that bug...). for the end user the most helpfull thing would be documentation at the moment, i think. cu robert --=20 Robert Lemmen http://www.semistable.com=20 |
|
From: Bob R. <bo...@br...> - 2004-04-27 13:11:38
|
On Tue, Apr 27, 2004 at 02:36:33PM +0200, Robert Lemmen wrote: > On Mon, Apr 26, 2004 at 10:54:12AM -0400, Bob Rossi wrote: > > I just released cgdb-0.4.1 which only contained minor bug fixes. > > However, I realized that maybe I should be giving the package maintaine= rs > > a look at the release before I put it up on soureforge and freshmeat. > >=20 > > Would it be helpful for the package maintainers to know ahead of time if > > a release is going to be made? or is the current system fine for now? >=20 > it would be helpfull for me because if problems with the packaging arise > we could include the fixes in the official upstream release too, but i > doubt it's a good idea. i can't guarantee to react to upstream releases > within a few days every single time, and until now none of the releases > had any problems wrt packaging. i think it's all fine the way it is. >=20 > btw, i saw that you fixed the hurd problem, but how about #228602? Unfortunatly, it has not been fixed yet. This is because, I need to do some fundamental error checking/reporting changes that I haven't had time to do. However, if you would like me to just fix that one bug (that case) I can do that. Does that help on the debian side of things? Bob Rossi |
|
From: Robert L. <rob...@se...> - 2004-04-27 12:36:40
|
On Mon, Apr 26, 2004 at 10:54:12AM -0400, Bob Rossi wrote: > I just released cgdb-0.4.1 which only contained minor bug fixes. > However, I realized that maybe I should be giving the package maintainers > a look at the release before I put it up on soureforge and freshmeat. >=20 > Would it be helpful for the package maintainers to know ahead of time if > a release is going to be made? or is the current system fine for now? it would be helpfull for me because if problems with the packaging arise we could include the fixes in the official upstream release too, but i doubt it's a good idea. i can't guarantee to react to upstream releases within a few days every single time, and until now none of the releases had any problems wrt packaging. i think it's all fine the way it is. btw, i saw that you fixed the hurd problem, but how about #228602? cu robert --=20 Robert Lemmen http://www.semistable.com=20 |
|
From: Bob R. <bo...@br...> - 2004-04-27 01:54:19
|
Hi, I just released cgdb-0.4.1 which only contained minor bug fixes. However, I realized that maybe I should be giving the package maintainers a look at the release before I put it up on soureforge and freshmeat. Would it be helpful for the package maintainers to know ahead of time if a release is going to be made? or is the current system fine for now? Thanks, Bob Rossi |
|
From: Mike M. <mmu...@cs...> - 2004-04-14 02:07:19
|
In the cgdb/Doxyfile, I added PREDEFINED =3D DOXYGEN, which will make Doxygen pass -DDOXYGEN to the preprocessor when you do 'make doxygen'.=20 This is an easy way to make Doxygen skip over a code fragment when it is parsing, so you don't get warnings about uncommented code (for example, test code where Doxygen generation is not desired). For example: #ifndef DOXYGEN /* Doxygen will never read this code */ #endif If anyone knows of a way to make Doxygen skip entire files, let me know.=20 I'm using this for now since it works for me... If it is useful enough, we can add it to the tgdb/ and various/ Doxyfiles. It'd be cool to see Doxygen run without warnings eventually. :) Mike |
|
From: SourceForge.net <no...@so...> - 2004-03-30 16:02:33
|
Bugs item #926068, was opened at 2004-03-30 07:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=534974&aid=926068&group_id=72581 Category: CGDB Group: version 0.4.* Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: CGDB Memory Leaks Initial Comment: I was using CGDB to debug a program that outputs a lot of text onto stdout and I noticed CGDB's memory footprint growing pretty large (over 400 MB). So I fired up valgrind and tracked down what looks like a few minor memory leaks in cgdb/src/cgdb.c: In the functions child_input() and gdb_input() a char *buf is malloc'ed but doesn't appear to have the memory freed anywhere. I'm attaching my updated cgdb.c from the 0.4.0 source package. Thanks for your work on this great program. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=534974&aid=926068&group_id=72581 |
|
From: Ronald Landheer-C. <ro...@la...> - 2004-03-12 20:51:57
|
Hello all, FWIW, I've just imported the glib hash code into libcontain and sealed off the C++ code so you don't get it if you configure with --without-cxx. I'm running tests on the library now. I've had to change some stuff that requires changes in some of my other software as well (the hash type has changed name) but that was coming anyway - so I might as well do it now. I haven't had time to write the proper documentation yet - it's on the TODO list. It's been checked into the Jail-ust CVS. I should note, however, that because the algorithms implemented by libcontain use some atomic operations (most notably compare-and-swap) which do not exist on all platforms (but can be emulated on most) portability in the sense of "as portable as gdb" is extremely difficult. This is mainly because, AFAIK, gdb doesn't need atomic operations at all (outside of the thread library if it uses one). The code in question is architecture-dependent. I have implemented the i486+ versions (applicable on all x86 platforms since i486) but on i386, a CAS-equivalent instruction is not available. The alternative would be to use atomic_increment and atomic_decrement around the compare and exchange operations, which is what is done in the "gen" version. However, as the atomic_increment and atomic_decrement functions are currently located in arch/i486 (because they haven't been verified to run on i386 yet) on i386, the library will simply not compile. The same basically goes for all architectures not supported by the arch-part of the library - which currently only supports i486 and up. It should be rather trivial to implement the proper functions for SPARC architectures, which have a CAS instruction, as well as for PowerPC architectures which can emulate such an instruction. However, as I don't know squat about the SPARC or PPC instruction sets, I won't be able to do that myself. An obvious work-around for all this would be to simulate the architecture- dependant calls on architectures they have not been implemented for, with locks to simulate atomicity. Those locks would take the form of mutexes provided by the threading library. Though that would be a viable solution, it would be dead slow (compared to the actual atomic versions). Another quick solution would be to take the code from a BSD distribution (the BSD license is compatible with the Jail license and doesn't require me to take the types of precautions I'll have to take for the glib code) such as OpenBSD - renowned for its portability. In any case, "as portable as gdb" is practically impossible because gdb doesn't require atomicity or thread-safety from its host platforms: if the host platform doesn't have threads, gdb won't need it to work whereas libcontain assumes that its host platform will have thread-support and therefore requires it (from the bottom up). rlc |
|
From: Bob R. <bo...@br...> - 2004-03-08 14:46:26
|
> >Are you interested in starting libcontain with the data structures from > >Glib? But changing the interface, typedef's, ... so that you can change > >the implementation later to whatever you want. > > > >I would be interested in porting away the code and committing them to > >libcontain. > > > >CGDB, could then merge libcontain into it every time some nice new > >improvement came along. That way, you would get a head start on the > >data structures you need, and CGDB could use libcontain.=20 > > > >It could be a marvelous relationship :) > > > That would place libcontain under GNU LGPL (it is under a BSD-GPL double= =20 > license right now) but it would definitely get libcontain a lot further= =20 > on its road. > (... thinking ...) >=20 > yeah, why not :) >=20 > I'll have to isolate the glib code from the rest of my code pretty=20 > clearly, though, so I don't end up re-licensing Jail-ust, but LGPL is=20 > not as virulent as GPL so it should be OK. >=20 > I'll get right on it. I already ported glist, ghash and gtree out of Glib. I removed all of the typedef's, things like typedef void* gpointer. I am now commenting the interfaces with doxygen style comments. These are the 3 ADT's that CGDB will need right away. I could have them "CGDB" ready in a few days, then I could give them to you to do what you want with after that. Does this sound good? The only reason I already started porting these 3 is because I need them before I can begin implementing libkui. To be perfectly honest, I am glad we didn't link in glib. The interface isn't all that great, and some of the data structures I think are implemented poorly. Also, functions like "g_tree_remove" do not return an error value. So, you have no idea if the remove was successful or not. These types of things I do not particularly like and didn't really expect from a library as popular as Glib. Thanks, Bob Rossi |
|
From: Ronald Landheer-C. <ro...@la...> - 2004-03-08 14:29:49
|
Bob Rossi wrote: >On Thu, Mar 04, 2004 at 09:25:17PM +0100, Ronald Landheer-Cieslak wrote: > > >>Bob Rossi wrote: >> >> >> >>>Hi, >>> >>>I am leaning towards option 3. Glib is widely used and comes with a >>>testsuite. I found that CGDB could have support for these ADT's >>>1. garray >>>2. ghash >>>3. glist >>>4. gqueue >>>5. gtree >>>6. gstring ? >>>7. gcompletion?, >>> >>>These are 5-7 of the 49+ files that are delivered with glib. It would >>>take about 1 week to abstract these files out of Glib, and then CGDB >>>would have access to these ADT's. If we go down this route, we area also >>>left with another question. Should we update the files when Glib >>>changes? or should we check them in with different names and totally >>>diverge from Glib? >>> >>>I would appreciate a response, since I can not continue development on >>>CGDB until this issue is resolved. >>> >>> >>> >>> >>If you're looking for a widely-used already-existing C implementation of >>a set of ADTs (and only ADTs) that will run OOTB on every platform >>supported by GDB, I'm afraid you might be asking a bit too much. It is >>what libcontain aims to become (other than being "blindingly fast", >>thread-safe for all operations, etc.) but that is precisely because such >>a library - to my knowledge, doesn't exist yet. >> >> > >Are you interested in starting libcontain with the data structures from >Glib? But changing the interface, typedef's, ... so that you can change >the implementation later to whatever you want. > >I would be interested in porting away the code and committing them to >libcontain. > >CGDB, could then merge libcontain into it every time some nice new >improvement came along. That way, you would get a head start on the >data structures you need, and CGDB could use libcontain. > >It could be a marvelous relationship :) > > > >>My personal preferences and pet projects aside, glib seems to be a very >>good choice, provided it really is very portable. If you do choose to go >>that way, please just make sure that the parts of glib you choose are >>cleanly cut out of glib and that you don't get left with any instable >>code that would have worked if glib had been there. Other than that, >>*please* make sure you can revert back to the state before integration >>of glib code (e.g. by doing it on a branch first and letting us porters >>have a go at it before merging it into HEAD). >> >> > >Ok, I will add the new ADT classes to a branch. > > > >>As far as keeping up with glib is concerned - I wouldn't bother: be on >>the lookout for bugs that are found in their implementation, but don't >>bother taking on new features they might add - you probably won't need >>them anyway. >> >> > >You are right. >I don't ever plan on keeping up with Glib after the port. > > That would place libcontain under GNU LGPL (it is under a BSD-GPL double license right now) but it would definitely get libcontain a lot further on its road. (... thinking ...) yeah, why not :) I'll have to isolate the glib code from the rest of my code pretty clearly, though, so I don't end up re-licensing Jail-ust, but LGPL is not as virulent as GPL so it should be OK. I'll get right on it. rlc |
|
From: Bob R. <bo...@br...> - 2004-03-04 22:15:34
|
On Thu, Mar 04, 2004 at 09:25:17PM +0100, Ronald Landheer-Cieslak wrote: > Bob Rossi wrote: >=20 > >Hi, > > > >I am leaning towards option 3. Glib is widely used and comes with a > >testsuite. I found that CGDB could have support for these ADT's=20 > >1. garray > >2. ghash=20 > >3. glist > >4. gqueue > >5. gtree > >6. gstring ? > >7. gcompletion?,=20 > > > >These are 5-7 of the 49+ files that are delivered with glib. It would > >take about 1 week to abstract these files out of Glib, and then CGDB > >would have access to these ADT's. If we go down this route, we area also > >left with another question. Should we update the files when Glib > >changes? or should we check them in with different names and totally > >diverge from Glib? > > > >I would appreciate a response, since I can not continue development on > >CGDB until this issue is resolved. > >=20 > > > If you're looking for a widely-used already-existing C implementation of= =20 > a set of ADTs (and only ADTs) that will run OOTB on every platform=20 > supported by GDB, I'm afraid you might be asking a bit too much. It is=20 > what libcontain aims to become (other than being "blindingly fast",=20 > thread-safe for all operations, etc.) but that is precisely because such= =20 > a library - to my knowledge, doesn't exist yet. Are you interested in starting libcontain with the data structures from Glib? But changing the interface, typedef's, ... so that you can change the implementation later to whatever you want. I would be interested in porting away the code and committing them to libcontain. CGDB, could then merge libcontain into it every time some nice new improvement came along. That way, you would get a head start on the data structures you need, and CGDB could use libcontain.=20 It could be a marvelous relationship :) > My personal preferences and pet projects aside, glib seems to be a very= =20 > good choice, provided it really is very portable. If you do choose to go= =20 > that way, please just make sure that the parts of glib you choose are=20 > cleanly cut out of glib and that you don't get left with any instable=20 > code that would have worked if glib had been there. Other than that,=20 > *please* make sure you can revert back to the state before integration=20 > of glib code (e.g. by doing it on a branch first and letting us porters= =20 > have a go at it before merging it into HEAD). Ok, I will add the new ADT classes to a branch. > As far as keeping up with glib is concerned - I wouldn't bother: be on=20 > the lookout for bugs that are found in their implementation, but don't=20 > bother taking on new features they might add - you probably won't need=20 > them anyway. You are right. I don't ever plan on keeping up with Glib after the port.=20 Thanks, Bob Rossi |
|
From: Ronald Landheer-C. <ro...@la...> - 2004-03-04 21:48:26
|
Bob Rossi wrote: >Hi, > >Well, CGDB is experiencing another round of development. With this, I >and other developers have found that we can not continue to write CGDB >without having some core ADT's that CGDB can rely on. This is >inevitable. > >So, there are 3 choices that I can think of. >1. Write a libadt ( from scratch ) >2. Use an existing library ( out of the box ) >3. Modify an existing library. > >I think that solution 1 is not a good solution. The goal of this project >is not to write and test a new C ADT library, but to get a curses based >debugger to GDB working :) > >I have searched the web for the last few days, and in my disgust, have >come to find that there is not a single, widely used implementation, of a >set of ADT's that can be used in C. So, I don't think option 2 is viable >either. If someone can find a library this is good to use and is >portable, please let me know. > >I am leaning towards option 3. Glib is widely used and comes with a >testsuite. I found that CGDB could have support for these ADT's >1. garray >2. ghash >3. glist >4. gqueue >5. gtree >6. gstring ? >7. gcompletion?, > >These are 5-7 of the 49+ files that are delivered with glib. It would >take about 1 week to abstract these files out of Glib, and then CGDB >would have access to these ADT's. If we go down this route, we area also >left with another question. Should we update the files when Glib >changes? or should we check them in with different names and totally >diverge from Glib? > >I would appreciate a response, since I can not continue development on >CGDB until this issue is resolved. > > If you're looking for a widely-used already-existing C implementation of a set of ADTs (and only ADTs) that will run OOTB on every platform supported by GDB, I'm afraid you might be asking a bit too much. It is what libcontain aims to become (other than being "blindingly fast", thread-safe for all operations, etc.) but that is precisely because such a library - to my knowledge, doesn't exist yet. My personal preferences and pet projects aside, glib seems to be a very good choice, provided it really is very portable. If you do choose to go that way, please just make sure that the parts of glib you choose are cleanly cut out of glib and that you don't get left with any instable code that would have worked if glib had been there. Other than that, *please* make sure you can revert back to the state before integration of glib code (e.g. by doing it on a branch first and letting us porters have a go at it before merging it into HEAD). As far as keeping up with glib is concerned - I wouldn't bother: be on the lookout for bugs that are found in their implementation, but don't bother taking on new features they might add - you probably won't need them anyway. That's my $0.02 :) @+, Ronald |
|
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: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: 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 |
|
From: Bob R. <bo...@br...> - 2004-03-03 23:01:32
|
Hi, Well, CGDB is experiencing another round of development. With this, I and other developers have found that we can not continue to write CGDB without having some core ADT's that CGDB can rely on. This is inevitable. So, there are 3 choices that I can think of. 1. Write a libadt ( from scratch ) 2. Use an existing library ( out of the box ) 3. Modify an existing library. I think that solution 1 is not a good solution. The goal of this project is not to write and test a new C ADT library, but to get a curses based debugger to GDB working :) I have searched the web for the last few days, and in my disgust, have come to find that there is not a single, widely used implementation, of a set of ADT's that can be used in C. So, I don't think option 2 is viable either. If someone can find a library this is good to use and is portable, please let me know. I am leaning towards option 3. Glib is widely used and comes with a testsuite. I found that CGDB could have support for these ADT's=20 1. garray 2. ghash=20 3. glist 4. gqueue 5. gtree 6. gstring ? 7. gcompletion?,=20 These are 5-7 of the 49+ files that are delivered with glib. It would take about 1 week to abstract these files out of Glib, and then CGDB would have access to these ADT's. If we go down this route, we area also left with another question. Should we update the files when Glib changes? or should we check them in with different names and totally diverge from Glib? I would appreciate a response, since I can not continue development on CGDB until this issue is resolved. Thanks, Bob Rossi |
|
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: 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 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 |
35 messages has been excluded from this view by a project administrator.
