From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15444 invoked by alias); 13 Jul 2007 20:21:23 -0000 Received: (qmail 15435 invoked by uid 22791); 13 Jul 2007 20:21:23 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jul 2007 20:21:20 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw1.br.ibm.com (Postfix) with ESMTP id 7CE0F14827B for ; Fri, 13 Jul 2007 17:06:26 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6DKJxS31753300 for ; Fri, 13 Jul 2007 17:19:59 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6DKHOrN018671 for ; Fri, 13 Jul 2007 17:17:24 -0300 Received: from dyn532128.br.ibm.com (dyn532128.br.ibm.com [9.18.238.251]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6DKHNMV018639; Fri, 13 Jul 2007 17:17:23 -0300 Subject: Re: GDB in C++ From: Thiago Jung Bauermann To: Michael Eager Cc: gdb@sources.redhat.com, Gary Funck In-Reply-To: <469590D2.4030202@eagercon.com> References: <00b601c7bda5$a5e6fa60$0a0a0a0a@DELORIAN> <1184183253.5515.51.camel@localhost.localdomain> <469590D2.4030202@eagercon.com> Content-Type: text/plain Date: Fri, 13 Jul 2007 20:21:00 -0000 Message-Id: <1184357966.23670.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00119.txt.bz2 On Wed, 2007-07-11 at 19:24 -0700, Michael Eager wrote: > Thiago Jung Bauermann wrote: > > If GDB Internal's contents was transferred to the GDB wiki, maybe people > > would feel more compelled to update and expand it. I know I would try to > > contribute to it as I learn new stuff. The downside when comparing to > > patches against the existing documentation sources would be that peer > > review would be a bit more awkward (but there are ways around it). > > The problems with the GDB documentation are not whether it lives > in a .texi file or in a .html file. The problem is in the content. It seems most people here don't see much of an advantadge in moving docs to the wiki. That's fine for me, I don't have a strong opinion about that. As you say, the main problem is that the documentation is not being given much priority. > There are two related fixes for this problem. (Possibly three, > with the first one being recognition that there is a problem.) > > 1) The knowledge that the experienced GDB developers have about the > program needs to be added to the documentation. This can either be > by them writing the docs or by them working with a less experienced > developer who writes the docs. (You might remember that I offered > to be the latter a short while ago, but I got no takers.) > > 2) The recognition that some of the problems with the documentation > stem from the fact that GDB is complex, cryptic, unclear and > convoluted. There are a number of ways to address this with > significant refactoring of the code into separate modules with > well defined interfaces being one, as well as my previous > suggestion to convert to using real object oriented code instead > of awkwardly trying to simulate it. I think this thread is important because it brings forward the issue that there is a barrier for new folks who would like to contribute code to the GDB project. I think that both of the fixes you mention above should be implemented. Regarding point 2: GDB is such an old project, and because of this there's a lot of cruft which is not easily identifiable by those who are not familiar with the code or the historic issues behind it. (that's why I mentioned "pitfalls" in my earlier e-mail). I hope we can get to some conclusion regarding this. Even if it is that the interested parties (me, for instance) should just send patches to the internals texinfo file. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center