Re: Summer of Code 2009: Emacs project suggestion

[R. Bernstein]

Nick Roberts writes:
 > [I'm not sure who address@hidden is but I've kept the cc. there]
 > 
 > Hi Rocky,
 > 
 >  > Something related to this. A while back Anders Lindgren and I (but
 >  > mostly Anders) started working on debugging support in emacs for other
 >  > languages, Ruby in particular. See
 >  > http://rubyforge.org/projects/ruby-debug/ The Emacs code is bundled in
 >  > ruby-debug-extra (See http://rubyforge.org/frs/?group_id=1900). We
 >  > hooked into and used parts of gdb-ui.el, but ultimately it would be
 >  > nice to see some of that and parts of what's in ruby-debug-extra
 >  > merged and bundled on its own. This core code would be independent of
 >  > front-end for specific languages and specific back end debuggers.
 > 
 > 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.

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.

 > 
 >  > Of the debuggers I've worked on that have emacs interfaces
 >  > (ruby-debug, pydb, bashdb, zshdb, kshdb, and remake mdb) none of them
 >  > support the MI interface only because it looked more complicated and I
 >  > couldn't find a nice succinct description of it. Right now some of
 >  > them have bastardized "annotation" interface.
 > 
 > 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...?

XML, YML and PostScript also suffer this problem? 

 > 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.

 > 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?

 > 
 >  > 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.


 > 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.

 > 
 > -- 
 > Nick                                           
 > http://www.inet.net.nz/~nickrob
 > 
 >