New GNOME Debugger checked into CVS
- From: Dave Camp <campd oit edu>
- To: gnome-debugger-list gnome org
- Subject: New GNOME Debugger checked into CVS
- Date: 11 Jan 2000 18:22:35 -0800
For the past month, I have been working on a rewrite/reorganization of Dryad
and the GNOME Debugging Framework. I have just checked these modules
into CVS. They can be found in the dryad and gnome-debug modules.
What is in the modules
gnome-debug contains the bulk of the GNOME Debugging Framework. It currently
contains a set of GnomeControls that can be embedded into applications, an
event server, a GDB backend based on the old libdryad (which will soon be
deprecated), the IDL for the project, and a general-purpose library for
communicating with the various parts of GDF.
dryad contains a DDD-style standalone debugger build from the GDF components.
It is a fairly small module, as most of the functionality is in gnome-debug.
What is Done
This is still nowhere near complete, but it is getting there quickly. Right
now it does breakpoint management and execution fairly well. Other things
like variable viewing and the stack are not yet done.
The biggest limitation in the framework at the moment is the libdryad backend.
This backend is basically crap, and was just used to get the project off the
ground. We need to discuss what we will do for a more powerful backend.
Should we wait for the new libgdb, hack our own libgdbish thing, or continue
work on gdb-guile?
Many features will have to wait on this decisision, because the libdryad
backend is limited, and working to improve it is basically a waste of time.
Some basic improvements can be made to libdryad, but most things (variable
watching, in particular) need to wait until we get a real backend.
How GDF Works
It is worth mentioning how GDF works from a client's perspective, since I
have changed the basic model a bit.
The client creates a number of GnomeControl objects (using the standard
bonobo methods for working with controls), and places them however it wants.
It then creates a Commander object for each program it wants to debug. Then
it sets a "commander-ior" of each control that it wants to associate with
the commander. The client can then manipulate the commander, and all of the
controls will keep synchronized with the commander.
What is Different
Here is a quick overview of what is different between this and the old
* gnome-debug is "larger" than it used to be -- Some things from dryad (the
controls) and ggdb (the backend) have been placed in gnome-debug.
* The Session Manager has been removed. OAF should be able to handle the
responsibilites of the SM (once OAF is done and gdf is ported to use it).
* All UI components are GnomeControls rather than GnomeEmbeddables (this was
planned before, but never done).
* All controls are in a single server rather than one server per control.
This cuts down on the number of processes GDF uses, and makes things
* Other little things I can't remember off the top of my head.
Bonobo (see caveats)
This is still not even close to done, and will be useful only for those
interested in developing gnome-debug/dryad.
As I write this, Bonobo has a bug that prevents dryad from working properly.
I have submitted a patch to gnome-components-list, but it has not yet been
approved. So you will need to make the following changes to bonobo:
1) If you are on gnome-components-list, or want to look at the archives, you
can apply the patch I sent there a few hours ago.
2) If not, you can make the following two-or-three-line change to temporarily
RCS file: /cvs/gnome/bonobo/bonobo/gnome-property-bag.c,v
retrieving revision 1.10
diff -u -r1.10 gnome-property-bag.c
--- gnome-property-bag.c 1999/12/13 20:45:22 1.10
+++ gnome-property-bag.c 2000/01/11 22:54:30
@@ -224,9 +224,11 @@
pb->priv->poa = property_poa;
* Create a list of CORBA policies which we will apply to our
* new POA.
@@ -314,7 +316,9 @@
property_poa = pb->priv->poa;
* Create our ServantManager.
Hopefully this will be fixed soon in Bonobo.
[Date Prev][Date Next
] [Thread Prev][Thread Next