From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28878 invoked by alias); 26 Jul 2008 19:34:52 -0000 Received: (qmail 28868 invoked by uid 22791); 26 Jul 2008 19:34:51 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Jul 2008 19:34:32 +0000 Received: from HOME-C4E4A596F7 ([77.127.123.9]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K4M00D2LP1L7FY1@i_mtaout2.012.net.il> for gdb-patches@sourceware.org; Sat, 26 Jul 2008 22:34:33 +0300 (IDT) Date: Sat, 26 Jul 2008 19:34: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/msg00501.txt.bz2 > Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org > From: Tom Tromey > Date: Sat, 26 Jul 2008 12:44:33 -0600 > > >>>>> "Eli" == Eli Zaretskii writes: > > >> 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. > > Eli> But the goal is the same: create user-defined commands, isn't it? Or > Eli> is there something else? > > There's a distinction to be aware of here ... what we have and what is > planned are not identical. I was talking about what was planned. > For instance, you will be able to write new "gdb-side" functions in > Python; this is related to exprsseion evaluation, not new commands. Sorry, I don't understand. Can you give an example, please? > And, you will be able to script gdb in any number of ways. What do you mean by "script gdb"? > Some of the immediate things will not be visible as user commands. > For example, pretty-printing will not be exposed that way. It will be > part of the "print" command (or just automatic in the MI case). If it's automatic, it's part of GDB and there's no need to mention it in the manual. For non-MI cases, are you talking about some kind of hooks into which user-defined Python code can be plugged to modify how certain objects are printed? > However, library authors and the like will be able to write new > pretty-printers How will those pretty-printers be invoked by GDB? > Long term I want to make it possible to fully script gdb. In > particular I want to be able to start a python script with > "#!/usr/bin/gdb" and have it completely control execution. For what purpose? 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.