From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4631 invoked by alias); 12 Jul 2007 02:24:51 -0000 Received: (qmail 4623 invoked by uid 22791); 12 Jul 2007 02:24:50 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.BAYAREA.NET (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jul 2007 02:24:46 +0000 Received: (qmail 7325 invoked from network); 11 Jul 2007 19:24:42 -0700 Received: from 209-128-106-254.bayarea.net (HELO ?192.168.20.7?) (209.128.106.254) by shell4.bayarea.net with SMTP; 11 Jul 2007 19:24:42 -0700 Message-ID: <469590D2.4030202@eagercon.com> Date: Thu, 12 Jul 2007 02:24:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Thiago Jung Bauermann CC: gdb@sources.redhat.com, Gary Funck Subject: Re: GDB in C++ References: <00b601c7bda5$a5e6fa60$0a0a0a0a@DELORIAN> <1184183253.5515.51.camel@localhost.localdomain> In-Reply-To: <1184183253.5515.51.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed 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/msg00109.txt.bz2 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. The problem is that the GDB docs are, to a large degree, incomplete, obsolete, unclear, cryptic, and several other adjectives I'll have to search for in my thesaurus. While a wiki has some nice features, it would be not closely tied to any particular GDB version, nor are changes likely to be reviewed for correctness as would be the case with a patch to the docs in the source tree. GDB has been undergoing a number of significant changes between versions. The information on a wiki would have no more likelihood of being accurate than the current docs. 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. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077