March-June Status

[Dodji Seketeli <dodji seketeli org>]

Hello,

Apparently, this is the season of status report concerning Nemiver.  So
I thought I'd throw my hat into the game as well.  What follows is a
status report of the changes that have hit our code repository since
March.  I'll post another message a bit later about what I am planning
to work on.

[0.8.2 released from tgtk2-branch]

We recently released Nemiver 0.8.2.  That release was based on the
gtk2-branch branch.  It should hopefully work on a maximum number of
GNOME systems out there.

[master branch is ported to GTK 3]

In the mean time, Kalev Lember has been busy working on porting
Nemiver to GTK-3.  His work is available in the master branch.  Thanks
to his work and to the work of Fabien Parent, Nemiver now runs
natively on GNOME 3, using GTK 3 and GSettings.

[The Memory Editing Widget has momentarily gone poof in master]

Unfortunately, the Ghex hexadecimal editing widget (which is de-facto
the only hexadecimal widget present in the GNOME source code
repository) hasn't been ported to GTK 3 yet.  It follows that the
memory editing widget has momentarily disappeared from the Nemiver
build of the master branch, as it uses the Ghex widget.

[0.8.2 back-ported to el6-branch]

On the boring department, I have back-ported the features and the bug
fixes of that release into the el6-branch, so that we can have a
decently recent version of the debugger that runs on RHEL-6 and
similar systems.  The name of the tag that rubber stamps the 0.8.2
version of Nemiver on that branch is nemiver-0.8.2el6.  Similarly, the
version that contains the fixes and features of 0.8.2 on that branch
is named 0.8.2el6.  FWIW, I have rolled out a package for this version
in the EPEL6 branch of Fedora.

[Changes to IDebugger event API]

And now for some technically detailed changes that we started.

When the UI layer requests a debugging action from IDebugger, the
implementation of that later interface emits a GDB command and when
the command completes, IDebugger emits an event to notify the UI layer
about the completion status of the debugging action.

IDebugger has a fixed set of events to which the UI layer can register
a callback that will be called whenever that event is emitted.

Each IDebugger function which can be used to request a debugging
action that will likely trigger an event takes a string parameter
dubbed "cookie".  Each event callback function also takes a cookie.

Once the GDB command has completed, the implementation of the
IDebugger interface calls the event callback that have been registered
to the event.  It passes the cookie received from the UI layer [passed
to the function that triggered the debugging action to begin with] to
the callback.  By looking at the cookie, the code of the callback can
have a hint about the context in which the UI layer called the
IDebugger entry point to begin with.

During the disassembling and jump-to work, it turned out that the
whole cookie shebang was too complicated to handle and not enough
flexible.

I have started to modify the relevant IDebugger functions to make them
take a callback instead.  That callback is called whenever the
debugging action completes.  Whenever the UI layer wants different
actions to be performed [upon occurrence of a given event] depending
on some context, it can, e.g, register a different callback per
context.

The practical challenge here is to avoid breaking the existing code
that uses the cookie API.  So for now I have duplicated the functions
taking cookies and changed the new version to make it take a callback
in parameter.  I plan to migrate the code base progressively to the
cookie-less IDebugger functions, and eventually remove the cookie
based functions.

Thanks for reading so far, and happy debugging!

-- 
		Dodji