From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8569 invoked by alias); 26 Jul 2008 18:29:34 -0000 Received: (qmail 8560 invoked by uid 22791); 26 Jul 2008 18:29:33 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Jul 2008 18:29:07 +0000 Received: from HOME-C4E4A596F7 ([77.127.123.9]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K4M00DKSM0HDZ10@i-mtaout1.012.net.il> for gdb-patches@sourceware.org; Sat, 26 Jul 2008 21:29:05 +0300 (IDT) Date: Sat, 26 Jul 2008 18:29: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: Tom Tromey 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/msg00491.txt.bz2 > Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org > From: Tom Tromey > Date: Sat, 26 Jul 2008 12:00:24 -0600 > > >>>>> "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. But the goal is the same: create user-defined commands, isn't it? Or is there something else? > >> 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. Sounds like we agree that API should be together with the "python" command. > 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. It would have been 47 if I hadn't resisted the trend.