This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Meeting Agenda 2008-08-06

>>>>> "Keith" == Keith Seitz <> writes:

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

That is ok.  I was having a moment of doubt when I wrote that part of
the note.  Anyway -- I'm definitely not trying to pressure you, I'll
be a lot more direct in that unlikely event.

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

This is perfect.

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

I have wondered about this myself.  Not enough to do anything about
it... :)

I have noticed that the standard *.exp style is really wrong-looking,
though usually without being actually wrong.  I always figured that
was due to excessive cut and paste.

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

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


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

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


I understand this is a tough problem.  It is ok if you and Sami come
back and say that we have to tackle it incrementally -- write some
pieces, learn more, then iterate.  It would be nice if we could break
everything down into small, concrete tasks and have a complete project
outline at the beginning.  But, in this case, I understand if that
isn't possible.

One question is what is even possible.  Maybe we can answer this up
front.  I have heard from multiple people that perhaps the dreamy goal
of "cut-and-paste expressions from user source" is not reasonably
achievable for C++.  The idea, AIUI, is that properly parsing depends
on template instantiation, which is a huge pain due to "SFINAE"
... but I don't have a concrete evil test case.

The other question I have is whether we should try something
monumental ("reuse g++ front end" or "write our own c++ expression
parser"), or instead add features to and fix bugs in the existing
code.  Again, here I think it is ok if the two of you decide that we
ought to start with the existing code and then re-evaluate.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]