Re: Python API plans

[Tom Tromey <tromey at redhat dot com>]

>>>>> "AndrÃ" == Andrà PÃnitz <andre.poenitz@nokia.com> writes:

AndrÃ> I think inferior interaction (run/stop stuff) and breakpoint
AndrÃ> access are the big "missing" areas in Python support. From a
AndrÃ> frontend's point of view the missing "run control" is actually
AndrÃ> not that bad as it is sufficiently well supported by MI (in
AndrÃ> contrast to breakpoints), but from a CLI/Python user's point of
AndrÃ> view the priorities are probably inverted.

Yeah, I think so.  I am not as much an MI expert as I would like to
be... feedback like this is very valuable.

Tom> * Write Python wrappers for all MI commands, see:
Tom> http://sourceware.org/bugzilla/show_bug.cgi?id=11688

AndrÃ> Similar here. The effective gain seems limited, especially since quite
AndrÃ> a bit of the MI commands are not optimal themselves. As a really awful
AndrÃ> example: "-data-read-memory" produces a lot of unneeded "information"
AndrÃ> yet is so slow that a "dump binary memory"/read-from-file combination
AndrÃ> easily beats it by a factor of two or three. That behaviour should not 
AndrÃ> be wrapped in Python.

AndrÃ> I could imagine handling that item on a case-by-case base and spending
AndrÃ> an extra thought or two on each individual API might make more sense.

There are definitely MI features that, IMO, are not useful to Python.
Varobj comes to mind.

The idea behind this is to reuse all the existing ui-out machinery to
mostly automate Python wrappers to internals.  It isn't as nice as the
hand-written approach.

Given your comment I think a good first step would be to review the MI
docs to get an idea of what is missing from the Python API.  If we're
close enough to full coverage then we don't really need this.

Tom> * Make a new Expression object that represents a parsed expression.
Tom> Add a new gdb.parse method to create these, something like:
Tom> gdb.parse (EXPR, [BLOCK], [STOP_AT_COMMA]) -> gdb.Expression
Tom> This functionality is handy for writing certain kinds of commands.

AndrÃ> What's the use case? Keeping "anything" on the inferior side?

It can be handy to separate parsing from evaluation.
For example if you wanted to write the "log a variable" command, you
could use this to parse the expression, then keep the parsed
representation around so that evaluating it at the breakpoint would be
more efficient.

This reminds me, another possible breakpoint-related cleanup is pushing
more things into breakpoint_ops and then exposing this to Python.
It would be nice for various breakpoint-like commands in Python to have
more control over how their mechanics are presented to the user.

Tom> * "declare $var : type" - make $var a reference to

AndrÃ> I have a similar construct five times in my code (creating an
AndrÃ> initialized gdb.Value, but that 'declare' is the first step) I
AndrÃ> think having it handled in gdb would be nice, especially if it
AndrÃ> relieves me from figuring out when to add 'class ' to the type,
AndrÃ> and when to quote it etc to 'survive' gdb command line parsing.

Please file bugs for problems like this.  I think we've made big strides
in eliminating random quoting; we definitely want to know about
remaining bugs.

AndrÃ> Another open issue in the area is to provide a way to keep
AndrÃ> (structure) return values of inferior calls alive in the
AndrÃ> inferior. Right now the only way I am aware of to chain or nest
AndrÃ> inferior calls is to poke data back manually.

Yeah, we plan to fix this, it just isn't specifically a Python task.

Tom