Re: Python API problems

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joseph" == Joseph Garvin <joseph.h.garvin@gmail.com> 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