[Nemiver-list] nemiver new variable model

[Dodji Seketeli <dodji domain hid>]

Hello,

I have been working on a new variable model for Nemiver recently and I
would like to share the status of this work.

Position of the problem
=======================

When we query GDB for a compound variable - a C struct or more
generally a C++ class - GDB basically returns a variable tree that is
not completely populated with meaningful data. It means that we need to
walk the members of the returned variable and for each of the
members, query GDB for the exact information we need. That information
being essentially the value and the type of the members of the compound
variable.

Translated into Nemiver's lingo, we call
IDebugger::get_variable_value() to get a variable. This is an
asynchronous call. The event IDebugger::variable_value_set_signal()
gets later emitted by IDebugger when the variable is ready. The
variable is an instance of IDebugger::Variable, which is a
tree modelling the generic compound variable.

That instance of IDebugger::Variable has been sent to us by GDB in its
non-fully-populated form. The client code still needs
somehow to walk members of IDebugger::Variable and ask GDB for the type
and value of every single members of IDebugger::Variable. Of course,
each member of IDebugger::Variable is itself an instance of
IDebugger::Variable.

If you consider the fact that each call to IDebugger is asynchronous,
trying to walk the members of each IDebugger::Variable to fully
populate them turns the code of our variable browsing widgets into an
extremely crowded bag of bugs. I tried once, you don't want to do the
same.

A possible solution
====================

To shield client code from the machinery of asynchronously populating
variables received from the debugger engine, I have introduced the
IVarWalker interface.

An instance of IVarWalker can be connected to an instance of
IDebugger::Variable. After that, IVarWalker::do_walk_variable()
triggers the recursive populating of the connected IDebugger::Variable
instance. When populating is done, and
IVarWalker::visited_variable_signal() event is emitted. Upon
that event, the client code is assured to have a well populated
IDebugger::Variable at its disposal.

To handle multiple instances of IDebugger::Variable at the same time, I
have introduced the IVarWalkerList interface. It can be connected to a
list of of IDebugger::Variable and emits a
IVarWalkerList::visited_variable_signal() when a variable has been
completely visited and populated. Client code can listen to that
signal and easily access the fully populated instance of
IDebugger::Variable.

I believe that should remove most of the complicated code paths we had
in the LocalVarsInspector type until now. That type is the widget that
shows the variable in the bottom tab of Nemiver.

Get a prototype code
====================

git clone http://www.gnome.org/~dodji/nemiver.git dodji-nemiver.git
cd dodji-nemiver.git
git checkout -b variablemodel origin/variablemodel
./autogen.sh && make -j2 && sudo make install

That should compile and install a Nemiver where I new variable browsing
widget has been implemented based on the IVarWalkerList interface.

It kinda work. The only thing I have not yet implemented is the
dereferencing of pointers.

I will also have to recode the VarInspectorDialog widget as well, using
the IVarWalker interface. VarInspectorDialog is the dialog widget that
pops up to show a variable when you hit F12. It lets you show the
content of an arbitrary variable that you can type.

If you are interested at looking at the code,
src/dbgengine/nmv-i-var-walker.h and
src/dbgengine/nmv-i-var-walker-list.h are the interfaces, whereas
src/dbgengine/nmv-var-walker.cc and
src/dbgengine/nmv-var-walker-list.cc are the implementations.

The code of the new LocalVarsInspector is in
src/persp/dbgpersp/nmv-local-vars-inspector2.cc .

I will continue hacking on this topic to have it fully working and will
try to merge it back into svn as soon as it is ready.

Cheerio,

-- 
Dodji Seketeli
http://www.seketeli.org/dodji