From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12922 invoked by alias); 26 Jul 2008 18:00:50 -0000 Received: (qmail 12911 invoked by uid 22791); 26 Jul 2008 18:00:49 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Jul 2008 18:00:32 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6QI0Qug011585; Sat, 26 Jul 2008 14:00:26 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6QI0Pqa027090; Sat, 26 Jul 2008 14:00:25 -0400 Received: from opsy.redhat.com (vpn-10-41.bos.redhat.com [10.16.10.41]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6QI0PNP014816; Sat, 26 Jul 2008 14:00:25 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 5F73937824B; Sat, 26 Jul 2008 12:00:24 -0600 (MDT) To: Eli Zaretskii Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support References: <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> <1216653969.31797.6.camel@localhost.localdomain> <20080726134252.GA6077@caradoc.them.org> <20080726144138.GA9711@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Sat, 26 Jul 2008 18:00:00 -0000 In-Reply-To: (Eli Zaretskii's message of "Sat\, 26 Jul 2008 20\:40\:10 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00489.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: >> I don't really want to merge them. I don't think it provides much >> benefit to the reader of the manual. Eli> The benefit is more structure. Both Python support and the old way of Eli> defining user-defined commands is about the same thing: extending GDB. That is one way to look at it. But really they don't have that much in common. The "define" command creates new user-defined commands, which are sequences of gdb commands. The python command accesses the python interpreter. It is not really useful unless you already know python and want to use gdb's python api. So, it has a much narrower audience. >> It might make sense to document the "python" command alongside >> "define" or what have you -- but I think only barely, since the >> "python" command is kinda pointless without the rest of the API. Eli> I don't see why this invalidates the merge. Please explain. Well, there are two cases. In one case, we put the python command and all the python API documentation together in the "Commands" section. This means that if you read the manual straight through, you will get a lot of information about the CLI, then a very long diversion into the details of the Python API, and then more information about the CLI. In the other case, we can document the python command in one place, but then the API elsewhere. However, this will also be a pain to read. The python command is not useful unless you can also read about the API. So, readers will have to flip between two parts of the manual. Eli> Having too many chapters is not a good sign. This does not seem like a strong argument given that there are already 27 chapters. Tom