From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2010 invoked by alias); 26 Jul 2008 17:40:35 -0000 Received: (qmail 2002 invoked by uid 22791); 26 Jul 2008 17:40:34 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout4.012.net.il (HELO mtaout4.012.net.il) (84.95.2.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Jul 2008 17:40:14 +0000 Received: from HOME-C4E4A596F7 ([77.127.123.9]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4M00AGGJR23U30@i_mtaout4.012.net.il> for gdb-patches@sourceware.org; Sat, 26 Jul 2008 20:40:15 +0300 (IDT) Date: Sat, 26 Jul 2008 17:40:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: X-012-Sender: halo1@inter.net.il To: tromey@redhat.com Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: 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> X-IsSubscribed: yes 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/msg00486.txt.bz2 > Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org > From: Tom Tromey > Date: Sat, 26 Jul 2008 11:09:59 -0600 > > Daniel> Ok, in that case I have an alternative suggestion: how about renaming > Daniel> the combined scripting chapter, and putting both Python scripting and > Daniel> the existing information in the new chapter? > > I don't really want to merge them. I don't think it provides much > benefit to the reader of the manual. The benefit is more structure. Both Python support and the old way of defining user-defined commands is about the same thing: extending GDB. > 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. I don't see why this invalidates the merge. Please explain. > In the long run the Python chapter is going to be 99% documentation of > the Python API, something that will hold little interest to the casual > gdb user. That's why it will be in a different section. > I guess we could even go so far as to make a separate python API > manual. That seemed like more of a pain though; I wasn't sure what > the benefit of that would be either. I agree: there's no sense of having such a separate manual. Determining where we stop describing Python in the GDB manual will be a challenge, but it shouldn't IMO prevent us from trying to have some reasonable structure on the top level. Having too many chapters is not a good sign.