From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4562 invoked by alias); 26 Jul 2008 17:06:18 -0000 Received: (qmail 4550 invoked by uid 22791); 26 Jul 2008 17:06:16 -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 17:05:56 +0000 Received: from HOME-C4E4A596F7 ([77.127.123.9]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K4M00999I5BQ6B0@i-mtaout1.012.net.il> for gdb-patches@sourceware.org; Sat, 26 Jul 2008 20:05:36 +0300 (IDT) Date: Sat, 26 Jul 2008 17:06:00 -0000 From: Eli Zaretskii Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support In-reply-to: <20080726144138.GA9711@caradoc.them.org> X-012-Sender: halo1@inter.net.il To: Daniel Jacobowitz Cc: bauerman@br.ibm.com, 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> 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/msg00480.txt.bz2 > Date: Sat, 26 Jul 2008 10:41:38 -0400 > From: Daniel Jacobowitz > Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sourceware.org > > On Sat, Jul 26, 2008 at 05:01:14PM +0300, Eli Zaretskii wrote: > > > The bits added by > > > this patch are similar to canned sequences of commands ("define"), but > > > this is the first patch of hopefully many; you'll be able to use it > > > for more than just macros. > > > > Sorry, I don't understand this rationale (and what does it have to do > > with macros? what macros?). Please elaborate. > > Sorry, I'm used to thinking of user-defined commands as macros. > Sloppy choice of terminology. So are you saying that adding Python will enable features that are beyond user-defined commands (a.k.a. scripting)? If so, what are those features? > > My rationale is simple: we should have a single chapter for scripting, > > because that's where a reader would look for information on how to > > write GDB scripts. If there's sense to distributing this information > > between separate chapters, please explain what that is. > > Ok, in that case I have an alternative suggestion: how about renaming > the combined scripting chapter, and putting both Python scripting and > the existing information in the new chapter? I have no objections to renaming that chapter. > I don't think Python makes sense as a section of "Canned Sequences of > Commands", because Python scripts don't contain GDB commands. The chapter name doesn't say "GDB Commands", it says just "Commands". But let's not argue about that on which we agree ;-) > For example, we can pass a value or type and get back a friendlier > display value or type; the long-requested C++/STL pretty-printing > support. Maybe I'm missing something, because I don't see how this is different from what we have now. For example, the .gdbinit file distributed with Emacs already pretty-prints Emacs Lisp data types, as do the various GDB extensions for printing Qt data types that float around. They are all written in the current scripting CLI language. How will Python be different in this department?