Re: gdb/mi or python interface for front end

On 03/09/13 02:29, Bob Rossi wrote:
> On Fri, Aug 23, 2013 at 08:03:27AM -0600, Tom Tromey wrote:
>> Bob> I would like some advice. It currently uses annotate level 2
>> Bob> for communication. Should I look into gdb/mi or should i look
>> Bob> into scripting gdb with the python interface?
>>
>> Definitely stop using annotations.
> 
> In the process.

Sorry I missed this email.  I must have been on PTO and it slipped
through.  Yes, agreed, annotations must die! ;)

>> I think using Python is cool, but I must admit it has a couple of
>> potential drawbacks.  First, it limits the versions of gdb your tool can
>> use -- older gdbs do not have Python, and it is an optional feature
>> (though most distros build it in).
> 
> Which is why I'm still using annotations. Although that argument is
> getting older.


It's my goal to be able to make the Python API able to do what you
wish, but there are some gaps.  For example, we don't have
asynchronous and rich inferior control.  That will come, hopefully
sooner than later.  You can get around it pretty much right now with
gdb.parse_and_eval and other like commands, but the feedback is all
text, which is problematic (text changes, as do error messages, and
there is no mark-up).  Soon, I hope, I will write inferior control
into the Python API.


>> Also, it is not as complete as MI in
>> some ways, so you may encounter holes that you need to be filled before
>> you can implement some feature.
> 
> I'd like to avoid that.

MI is pretty much designed to be a complement for IDEs/UIs as it uses
the concept of a wire protocol to communicate with GDB.  My goal with
the Python API is to make the API better suited to specific goals of
tools that use GDB for a narrower focus.  So you can write specific
tool-based solutions using it, instead of the catch all focus of the
IDE.  I don't think it is worthwhile to write the Python API to
replace MI;  MI is a known quantity used for this very purpose.
That being said, if you can write an entire front-end with Python,
then I would consider that an end-goal of the Python API.


> I might end up with a hybrid approach. Bubble up my MI protocol and
> also support python programming. I'm going to dig deeper at some point
> in the future on this one.

If I can help you on your approach, I would be happy to help.  Either
on the mailing list, or on the #gdb irc channel on freenode.

Cheers,

Phil