Re: Summer of Code 2009: Emacs project suggestion

[Nick Roberts]

 >  > I'm aware of your work.  I'm happy that you are using parts of gdb-ui.el
 >  > but I'm not sure that our goals are the same.  I'm interested in
 >  > specifically getting GDB to work in Emacs.
 > 
 > In order to get "GDB to work in Emacs" there are a whole slew of
 > problems encountered and decisions that have to get made that are
 > really not specific to GDB, such as the way one shows in GNU Emacs
 > where the breakpoints have been set.

I'm not saying there aren't commonalities - indeed that is exactly what
Emacs' original gud.el exploited - just that there are differences.  There
will always be a tradeoff between a specialised tool that only does one thing
well and a general purpose one that does many things but none so well.

 > And one of the endemic problems concerning debuggers in general is
 > that many of them don't make much of an effort to use or follow a
 > common interface. Consider for example the command set for the gdb
 > versus the Perl debugger versus GNU Emacs edebug.  No doubt, their
 > goals are different. But if you step back for a second and consider
 > the lot of someone who may work in several of these languages, it's
 > kind of a mess.

If you want to promote a common interface for GDB, Perl and Lisp, I wish you
luck.  At times I've found it too hard to get my changes into GDB.  Also, when
I first started in 2002, I tried to get Python developers to add very basic
changes to make PDB more GDB-like and there was just about no interest.

 >  >... 
 >  > MI is a bit ugly but that's because GDB is a complex beast.  The problem
 >  > with annotations is that it marks up output intended for a human to read.
 > 
 > And making up output intended for a human to read is a problem because...?

As I say, because GDB developers may, and do, choose to change the syntax which 
can
easily break any parser that tries to read it as a string.

 > XML, YML and PostScript also suffer this problem? 

I don't know YML, but PostScript is intended for printers to read and XML is
designed for parsing like MI.  Although a human can read them, they have have a
more formal structure than the CLI output of GDB

 >  > That
 >  > means that the syntax might change at any time.  
 > 
 > I am not sure I follow the logic here of why if it's human readable it
 > means the *syntax* has to change.

It doesn't *have* to change, but it does because GDB changes.  A case in point 
is
the output of "info breakpoints" which was changed for pending breakpoints.  I 
had
to kick up a fuss to change it back and fight opinion that I was "using 
undocumented
assumptions"

 >  > In contrast, MI is more formal
 >  > output intended for parsing by computers, that should provide a more 
 > robust
 >  > interface.
 > 
 > So just as there are tools for parsing and working with XML or YML, are
 > there such tools for working with MI?

People have talked about writing such tools but MI has grown organically and
probably couldn't stand such scrutiny.

 >  > 
 >  >  > But I'm currently redoing pydb from the ground up and in the spirit of
 >  >  > ruby-debug will allow for pluggable "interfaces" one of which could be
 >  >  > a MI interface.
 >  > 
 >  > I'm not sure that MI is appropriate for Python.  
 > 
 > And by extension not appropriate for the other languages ksh, zsh,
 > bash, and Ruby? If that's the case, why not ditch MI and instead
 > switch to say something that is human readable and can be used in
 > systems other than gdb. For example, I think one of the Java
 > interfaces uses XML.

I'm not qualified to comment on these languages but they all seem to be
scripting languages and the impression I've got is that different debugging
techniques are preferred, e.g., Python developers rave about pdbtrack which, to 
me,
seems very lightweight.

 >  > Are you just communicating
 >  > to me what you have done or are you saying something else?
 > 
 > Part is communicating what's done and going on, but much more
 > important is that I was also making a plea to folks when doing work in
 > debugging systems and GNU Emacs to consider interfaces and tools that
 > could be reused more generally.
 > 
 > Given the limited resources, wouldn't it be nice to have the work done
 > in one area be reusable in another? It doesn't mean that one should
 > need to learn Python or Eclipse or whatnot. It might just mean
 > thinking about what you are doing in a reusable way, e.g. this part is
 > an Emacs UI part that's not specific to gdb, so let's break that out
 > into its own module, here's a common API for tagging and communicating
 > information, so let's use that rather than invent a new one.

It looks like you are already re-using gdb-ui.el and, of course, you will be
able to re-use any code that might come out of SoC but I want to focus on tasks
that I feel are achievable and, to me, that means just using/developing GDB/MI
for Emacs.

-- 
Nick