From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13570 invoked by alias); 30 Jan 2010 02:23:39 -0000 Received: (qmail 13561 invoked by uid 22791); 30 Jan 2010 02:23:38 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 Jan 2010 02:23:34 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o0U2NVY7015417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jan 2010 21:23:31 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o0U2NUeA031058; Fri, 29 Jan 2010 21:23:31 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o0U2NTw3015116; Fri, 29 Jan 2010 21:23:30 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 8C1B3379976; Fri, 29 Jan 2010 19:23:29 -0700 (MST) From: Tom Tromey To: Joseph Garvin Cc: gdb@sourceware.org Subject: Re: Python API problems References: Reply-To: tromey@redhat.com Date: Sat, 30 Jan 2010 02:23:00 -0000 In-Reply-To: (Joseph Garvin's message of "Wed, 27 Jan 2010 13:27:05 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.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: 2010-01/txt/msg00224.txt.bz2 >>>>> "Joseph" == Joseph Garvin writes: Sorry for the delay in this reply... Joseph> Unfortunately, under the current API, none of them are possible Joseph> AFAICT. Yeah. In gdb CVS the support is mostly for pretty-printing and nothing else; there is more on the appropriate Archer branch (and we're slowly pushing that upstream), but even there, there is a lot missing. Joseph> I wanted to be able to wildcard break on all the functions in a Joseph> particular C++ scope, so if I had a namespace called 'foo' I could do Joseph> this: Yeah, better symbol table stuff is on the wish-list. Feel free to file bugs for this or any other missing features, btw. Joseph> If break were exposed as a python function for example, it Joseph> could return a breakpoint object on which you could later in the Joseph> python code call enable/disable, or inspect to see what address or Joseph> line number was broken at (if for example you broke by function name). There is some breakpoint support on the branch. Joseph> -There's a lookup_type but not a more general lookup_symbol. It'd be Joseph> nice if such a function existed. Also, search_type and search_symbol Joseph> for matches to a regex. There is some symbol stuff on the branch, though I think not searching. Phil should have the symbol patch ready for submission soon, he's been working on that recently. Joseph> -That could be worked around if gdb.execute returned a string Joseph> containing what information would otherwise have gone to the console. This is http://sourceware.org/bugzilla/show_bug.cgi?id=10808 Also I have been thinking that we could make a new "MI-like" ui-out object that creates Python objects, so you could get structured output from at least some commands. Even if we did this the output would be fairly primitive objects -- ints and strings and whatnot, not Breakpoints or the like. The latter would require even more work. Instead I think we'll just expose the various interest APIs directly, as we've already done for value and types. Joseph> -You can't call the builtin completion functions. Basically I'd like Joseph> to call complete_symbols("foo::", "") to get a list of symbols in the Joseph> foo namespace, then iterate through them and break on each one. If in Joseph> my constructor I pass in gdb.COMPLETE_SYMBOL, I would expect then if I Joseph> call the base class version of complete, e.g. Joseph> gdb.Command.complete(self, "foo::", "") I would get back the results Joseph> of the builtin version of complete. But I don't, complete is not Joseph> defined. This doesn't feel very pythonic. I wouldn't mind a bug report for this. Joseph> -Needing to pass the name of the class to the constructor is silly. Joseph> Python has reflection facilities (see the 'inspect' module), gdb Joseph> should be able to inspect the class and figure out its name itself. You may want a multi-word name for your command. You may like this: http://sourceware.org/ml/gdb-patches/2010-01/msg00221.html Joseph> -Needing to manually instantiate an instance of the class *may be* Joseph> silly. Python's reflection could be used to look at the imported Joseph> classes and make instantiations of any classes defined to inherit from Joseph> gdb.Command. On the other hand, real pythonistas might be able to Joseph> conjure some hack that depends on commands being instantiated in an Joseph> order they define, so this isn't necessarily a good idea, but I can't Joseph> think of why someone would want to do that off the top of my head at Joseph> least. I tend to think that future APIs akin to this one will be a little more "duck-type-y" and a little less inheritance based. The inheritance thing is my java background showing through, oops. We're very interested in pushing the Python effort forward. It has been a little slow lately; right now Phil is working on Python stuff full-time, but he has been busy with fixing bugs and now patch wrangling. Tom