Re: Meeting Agenda 2008-08-06

[Keith Seitz <keiths at redhat dot com>]

Tom Tromey wrote:

> Not much information came out about when estimates will be ready, and
> I didn't press for this.  Honestly I wonder if this estimation thing
> is worth the effort -- comments?  On the one hand I think it is
> important to know what we are trying to do, and have at least some
> idea for how big these tasks are.  On the other hand, this task seems
> vague and I don't want folks to feel bogged down; also I'd rather
> avoid people having dead time.  So, what works for you?

I don't think asking for estimates is unreasonable, but I find myself in 
a position unable to give you anything useful right now.

As I mentioned in the meeting, I have been writing/revising a little C++ 
program (attempts to use lots of C++ features and misfeatures), and I've 
been writing a gdb test case to check some of the common commands (info 
func, break, print, ptype, whatis, list, TAB completion) to see how gdb 
behaves or misbehaves according to my expectations. You know, the 
simplest, most basic operations. [Yes, some of this may overlap with 
other tasks -- in particular the template stuff.]

I'm just trying to ascertain if gdb really has any clue about what 
"{break/list/ptype/print} foo::bar<int, baz<char*> >" really means. But 
perhaps this is not what your task meant by expression parsing?

I've encountered a ton of inconsistencies/bugs which makes writing this 
sort of test case nearly impossible, and I now appreciate (but remain 
unsympathetic) why gdb.cp's test cases are ridiculously contrived and 
trivial, because that's all gdb can do right now.

Alas, this has been much more tedious than I ever expected: gdb's test 
suite hackery on top of dejagnu is really an abomination of very 
confused Tcl code. [Or should I say very confused Tcl coders?]

Nonetheless, I am slowly beginning to identify some of the monumental 
problems and issues with symbol/expression parsing at the command line 
-- and a whole lot more that really kill gdb's usefulness with C++.

I hope that my test case will serve as a nearly complete functional 
requirement for this task (and perhaps a bit more). Yes, that's almost a 
form of documentation. :-)

My hope is to further elaborate this test "case" to do many more things 
that a C++ developer might do in a real debugging session (like stack 
and object examination, exceptions, etc). But first we need the basic 
operations I've list above fixed, and that's probably many weeks/months out.

So after all this, it seems that I can only say right now: "I'm working 
on it."

Keith