From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24713 invoked by alias); 9 Jun 2008 13:36:57 -0000 Received: (qmail 24702 invoked by uid 22791); 9 Jun 2008 13:36:56 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jun 2008 13:36:33 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id 7F09339008B for ; Mon, 9 Jun 2008 10:20:24 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m59DaUTn1384592 for ; Mon, 9 Jun 2008 10:36:30 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m59DaQG4017378 for ; Mon, 9 Jun 2008 10:36:26 -0300 Received: from [9.8.3.117] ([9.8.3.117]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m59DaQIE017365; Mon, 9 Jun 2008 10:36:26 -0300 Subject: Re: Function syntax (Was: [RFC][patch 1/9] initial Python support) From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: Tom Tromey , gdb-patches@sourceware.org In-Reply-To: <20080608182128.GA6248@caradoc.them.org> References: <20080608182128.GA6248@caradoc.them.org> Content-Type: text/plain Date: Mon, 09 Jun 2008 13:48:00 -0000 Message-Id: <1213018581.11485.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit 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-06/txt/msg00158.txt.bz2 On Sun, 2008-06-08 at 14:21 -0400, Daniel Jacobowitz wrote: > Except we do need to define what the arguments to specified functions > are, and I want a clear answer on that point before anything goes in. > They could be Python syntax, or some other well-defined syntax which > happens to be similar to Python. Would GDB convenience variables > work? As values or as textual substitution? What about separating argument by commas, and treating each CSV as an expression to be evaluated? The Python function would then receive arguments as value objects. This also means that convenience variables (and variables in the inferior) would work. The Python function would also return a value object. > > * 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? > > Yes, but this is always an issue defining new predefined convenience > variables since they share a namespace with user variables. I actually prefer the $func(...) syntax. Using $(func args) doesn't feel natural for non-LISP hackers. The former approach IMHO fits better with the current GDB syntax, and also with the imperative language used in the inferior. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center