From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19328 invoked by alias); 29 May 2008 20:30:06 -0000 Received: (qmail 19279 invoked by uid 22791); 29 May 2008 20:30:03 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 May 2008 20:29:44 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m4TKTePP004476; Thu, 29 May 2008 16:29:40 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m4TKTYVM013569; Thu, 29 May 2008 16:29:34 -0400 Received: from opsy.redhat.com (vpn-10-8.bos.redhat.com [10.16.10.8]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m4TKTXmF011525; Thu, 29 May 2008 16:29:34 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id E9F59378172; Thu, 29 May 2008 14:29:32 -0600 (MDT) To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org Subject: Function syntax (Was: [RFC][patch 1/9] initial Python support) References: <20080429155212.444237503@br.ibm.com> <20080429155304.288626880@br.ibm.com> <20080528205921.GA2969@caradoc.them.org> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Fri, 30 May 2008 13:07:00 -0000 In-Reply-To: <20080528205921.GA2969@caradoc.them.org> (Daniel Jacobowitz's message of "Wed\, 28 May 2008 16\:59\:21 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-05/txt/msg00762.txt.bz2 I think this response should be its own thread. Daniel> For the general syntax: Should we allow $() to always mean Python, or Daniel> are there other useful potential scripting interfaces or environment Daniel> variable access or anything, in which case we want $(python ) or $(P ) Daniel> or $python( )? There are only so many nice grouping specifiers. $<> Daniel> is not so good but we still have $[] and ${}, plus $env(). I don't Daniel> remember if we discussed this before, but we may have. Recently I've been thinking that $(...) should not simply eval the '...' as a python expression. Instead, I'm leaning more toward a function registry approach. I have two reasons for this. First, pure Python syntax is somewhat clunky for the gdb user. E.g., I used this to make a breakpoint conditional on the calling function: cond 1 $(gdb.current_frame().get_prev().get_name() == "declspecs_add_type") That's a lot of "()" for a pretty simple action. Instead, we could provide little helper functions and get: cond 1 $(caller-is "declspecs_add_type") The second reason is that with explicit registration and function objects (like the existing command objects) we could allow nicer completion inside the $(...). We can always provide a function named "python" to eval its argument. As to some of the other things you mentioned: * I agree with the lexing point. I think we could specify some standardized quoting and dequote before passing the argument to the underlying code. * I don't want to use $python(...) -- but I was wondering, doesn't this already have a meaning if 'python' happens to be a function-pointer-valued convenience variable? * I don't think we should worry about supporting any scripting language other than Python. Stuff like getenv access or reflective access to gdb 'set' variables can all be done via the python code. Anyway, the explicit-function-registration approach leaves open the possibility of built-in functions written in other ways. I suppose my basic proposal is that all functions be derived from something like: class Function: # ARG is a string, already de-quoted and whitespace-stripped. def invoke(self, arg): do something def complete(self, text, word): complete the argument This is basically exactly what we do for commands, only in the Function case we could expect invoke to return a value. Tom