Re: Python API plans

[Tom Tromey <tromey@redhat.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