From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26044 invoked by alias); 26 Jun 2008 00:24:57 -0000 Received: (qmail 26036 invoked by uid 22791); 26 Jun 2008 00:24:57 -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, 26 Jun 2008 00:24:39 +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 m5Q0Oc8P005842 for ; Wed, 25 Jun 2008 20:24:38 -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 m5Q0OblV015878; Wed, 25 Jun 2008 20:24:37 -0400 Received: from opsy.redhat.com (vpn-10-97.bos.redhat.com [10.16.10.97]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5Q0ObBH031810; Wed, 25 Jun 2008 20:24:37 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id AF38D378181; Wed, 25 Jun 2008 18:24:36 -0600 (MDT) To: gdb@sourceware.org Subject: Re: GDB Focus Group at the 2008 GCC Summit References: <20080619190942.GA3744@adacore.com> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Thu, 26 Jun 2008 00:24:00 -0000 In-Reply-To: (Tom Tromey's message of "Mon\, 23 Jun 2008 09\:15\:32 -0600") 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-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-06/txt/msg00266.txt.bz2 Tom> Our consensus was to use the function-like syntax (second example Tom> above) and to parse the arguments as expressions. I've pushed this to gitorious. Let me know if you run into problems. (I also pushed a fix for a pretty serious bug in the "python" command, so we are not exercising this code as much as I'd like... :) This change defines a new "internal function" type code. A newly-registered internal function is just a value with this type, which is assigned to a convenience variable of the given name. This underscores the need for the gdb.Value class to be much more robust. Arguments to an implementation of gdb.Function are boxed as Value objects. (I considered instead unboxing the 'struct value *'s into ordinary Python values, but I thought that perhaps it would be valuable for user functions to be able to access types, even types for scalars.) I think at the very least we need a way to unbox a Value. Perhaps we should also implement the full range of numeric operators. Tom