From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18729 invoked by alias); 26 Mar 2008 17:29:19 -0000 Received: (qmail 18720 invoked by uid 22791); 26 Mar 2008 17:29:18 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 17:29:01 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id m2QHSseg031791 for ; Wed, 26 Mar 2008 17:28:55 GMT Received: from wr-out-0506.google.com (wrac55.prod.google.com [10.54.54.55]) by zps35.corp.google.com with ESMTP id m2QHS0DG005411 for ; Wed, 26 Mar 2008 10:28:53 -0700 Received: by wr-out-0506.google.com with SMTP id c55so3009226wra.0 for ; Wed, 26 Mar 2008 10:28:53 -0700 (PDT) Received: by 10.141.67.21 with SMTP id u21mr249562rvk.222.1206552533172; Wed, 26 Mar 2008 10:28:53 -0700 (PDT) Received: by 10.141.142.4 with HTTP; Wed, 26 Mar 2008 10:28:53 -0700 (PDT) Message-ID: Date: Wed, 26 Mar 2008 18:05:00 -0000 From: "Doug Evans" To: "Tom Tromey" Subject: Re: repo to work on python scripting support Cc: "Thiago Jung Bauermann" , "gdb ml" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1205538908.6643.138.camel@localhost.localdomain> <1206369478.29533.15.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00240.txt.bz2 On Mon, Mar 24, 2008 at 10:32 PM, Tom Tromey wrote: > I've been thinking... maybe we do want $(...) to allow things other > than Python commands. Or, more precisely, maybe we want to let Python > code register a function by name for use in $(...). The Python > function would get the uninterpreted string argument for processing. OOC, Would there be an intent to not disallow dynamically loaded C/C++ instead of Python for $(foo)? [Emphasis on OOC.] > My reason is that after playing a bit, I'm not over-fond of the > verboseness and extra quoting required by the Python bits. It is more > gdb-ish, I think, not to do this. > > Any opinions? > > The canonical example is a function to match the calling function at a > breakpoint. gdb-ish: > > break inner if $(caller-is outer) > > Pythonic: > > break inner if $(gdb.caller_is ('outer')) Parsing two separate languages in one line is problematic too (I'm not sure how far the Pythonic version was intended to be interpreted).