From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10656 invoked by alias); 26 Mar 2008 18:41:02 -0000 Received: (qmail 10608 invoked by uid 22791); 26 Mar 2008 18:41:02 -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; Wed, 26 Mar 2008 18:40: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 m2QIecX4010959; Wed, 26 Mar 2008 14:40: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 m2QIeZ18032307; Wed, 26 Mar 2008 14:40:35 -0400 Received: from opsy.redhat.com (vpn-248-165.boston.redhat.com [10.13.248.165]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2QIeY16031649; Wed, 26 Mar 2008 14:40:35 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 152723780C2; Wed, 26 Mar 2008 11:44:39 -0600 (MDT) To: Doug Evans Cc: Thiago Jung Bauermann , gdb ml Subject: Re: repo to work on python scripting support References: <1205538908.6643.138.camel@localhost.localdomain> <1206369478.29533.15.camel@localhost.localdomain> <20080326180455.GA22644@caradoc.them.org> <20080326182505.GA2816@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Wed, 26 Mar 2008 18:55:00 -0000 In-Reply-To: <20080326182505.GA2816@caradoc.them.org> (Daniel Jacobowitz's message of "Wed\, 26 Mar 2008 14\:25\:05 -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-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/msg00247.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> No, I'm concerned about what the C-defined functions would include Daniel> or call to interpret the details. I don't want them including any Daniel> of GDB's normal headers. Gotcha, that makes sense to me. Long-term compatibility in the Python API is something we haven't discussed. I'm really not sure what to do about this -- we really are exposing a decent amount of gdb internals to the world this way. >> print $(py do something in python) Daniel> But what if there's quotes in there? Or parentheses, or both? Yeah. They have to match and if gdb does any processing (I didn't look into this), you have to know how to trick it. Talk about unsatisfactory... OTOH double-quoting the python code is also a bit yucky. But, I suppose this will be a relatively unusual thing to want to do. I'll try to implement this soon. So far my list of declarative argument "kinds" is: * expression * linespec (or whatever the thing that "break" takes is called) * filename (do we need it?) I was thinking that the declaration could be a tuple using named constants; string elements in the tuple would be looked for explicitly, like: (EXPRESSION "," EXPRESSION) would parse an expression, a comma (ignoring whitespace around it), and another expression. I guess we need a syntax for optional arguments as well, perhaps just a named 'OPTIONAL' constant in the tuple. Maybe we could do the same kind of parsing for commands. Tom