From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19363 invoked by alias); 30 Jul 2008 17:57:57 -0000 Received: (qmail 19348 invoked by uid 22791); 30 Jul 2008 17:57:57 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 17:57:37 +0000 Received: from HOME-C4E4A596F7 ([84.229.228.238]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K4T00005Z6BMYL0@i-mtaout6.012.net.il> for gdb-patches@sourceware.org; Wed, 30 Jul 2008 20:56:36 +0300 (IDT) Date: Wed, 30 Jul 2008 17:57:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: <1217429936.4804.12.camel@localhost.localdomain> X-012-Sender: halo1@inter.net.il To: Thiago Jung Bauermann Cc: tromey@redhat.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> <1217429936.4804.12.camel@localhost.localdomain> 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/msg00567.txt.bz2 > From: Thiago Jung Bauermann > Cc: Tom Tromey , gdb-patches@sourceware.org > Date: Wed, 30 Jul 2008 11:58:56 -0300 > > On Sat, 2008-07-26 at 22:34 +0300, Eli Zaretskii wrote: > > Bottom line, unless I'm again missing something, we are talking about > > extending GDB. CLI scripting is also a way of extending GDB, albeit > > very limited one. So I still think having these two in the same > > chapter is OK. > > It seems to me that the confusion comes from the fact that Python > scripting support can be viewed by two angles: a much more powerful > version of the current GDB scripting capability, and a way to develop > new features and functionality (even eligible to be shipped with GDB > itself) without having to mess around with GDB internals, by doing them > completely in Python. > > In the first sense, it makes sense to put the Python-related > documentation in the "Canned Sequence of Commands" chapter. In the > other, it doesn't because it's something different. And the audience of > each of those is different. Sorry, I'm unconvinced. Both features belong to a broader category of means of extending GDB.