[Nemiver-list] update

[Dodji Seketeli <dodji domain hid>]

Hello,

A lot of things have happened on the nemiver front recently.

[enhancement of the search dialog]

Jonner has improved the search dialog. It now remembers the search
terms you entered. He has also fixed some focus related issues around
that dialog.


[put the GDB/MI parsing code into a static library]

Yes. The file nmv-gdb-engine.c (the GDBEngine type) was too big,
obviously (more than 5000 lines). So I broke it down. The pure GDB/MI
(the wire protocol to control GDB) parsing code landed in
nmv-gdbmi-parser.[cc|h] which is now compiled as a static library. A
cool effect of that is that I have also written some unit tests for the
GDB/MI parsing code alone. The name of that library is
libgdbmiparser.a .

[isolate the abstraction of debugger commands]

Following the process of modularizing the GDBEngine type, I also have
have created a libdbgcommon.a library. It contain the types that
abstract the command sent to the underlying debugging engine, and the
results we get from it. This will ease somehow the job of supporting
other underlying debugging engines.

[put a proper automated test infrastructure in place]

I have investigated using the CppUnit framework. It didn't start that
bad. The basic unit tests we have were quickly ported over CppUnit.
Then I hit a wall. We have some tests that are less "unit" tests. They
need to create an IDebugger object, have it launch a program, set
breakpoints in it, run it, step into some of it functions etc ...
The problem I had is that the IDebugger API is asynchronous. When you
do things like:

IDebuggerPtr debugger = create_the_debugger () ;
debugger->load_program ("fooprog") ;
debugger->set_breakpoint ("main") ;
debugger->run () ;

What happens is that all the request you issue to IDebugger return
immediately. IDebugger later fires events to notify what
happened. You have to register event handlers to do the proper work
depending the event received. That is where CppUnit felt short.
It is good at launching a function, detect if the function failed, and
later report the status.

What I needed what a little bit different. I needed
something that would let you write the program want and put some
asserts at well chosen points of the program. When the program ends, if
no assert failed, the framework should say "yay, the test passed". That
and some variations around it.

Here is where boost::test comes into play. It lets me do that, and in a
simple fashion. So I switched to it.

Now, when you compile ./configure nemiver with the NEMIVER_DEVEL=on
variable set, the tests are compiled. You need the boost::test
library for that. After that, "make check" should launch the tests. yay.

There is a caveat though. You need to do make install *before* make
check. Yes, I know it's unfortunate. But it is due to the fact that we
need to install the dynmods (the basic dynamic modules used by nemiver)
to have the tests work. I am thinking about how to solve that
issue later.


[fix a lots subtle debugging engine control bugs]

Being able to perform more tests automatically, especially the
IDebugger level tests helped in spotting a certain number of subtle
bugs. They are related to the way we control the flow of commands we
send to GDB. In some cases, we were overflowing GDB with commands. So
it was just ignoring some of them, causing some subtle
de-synchronization with the IDebugger implementation. I fixed the
problems I have seen. Please, test svn trunk to see if I have caused
any regression.

[On going work on the new variable model]

I am still working on the new variables model. It is basically a new
type that represents a set of variables (you know, variables that are in
the target program being debugger) we want to care about. The model can
keep track of the variables and update them for you each time the
debugger stops. You can then just focus on value added tasks like nice
widgets to inspect the state of those variables, for instance.
It is far from being finished, but I am starting to have an idea about
how things should be done. More on this later.

That's all folks !

Cheers,

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