[Introspector-developers] Status report / Call for ideas

[James M. D. <mdu...@ya...>]

Dear All,

I bet you have been eagerly awaiting some form of life sign on this
list. After many discussions in private and much research, I think it
is time to get this list up and running with ideas and discussion.

I would like to get a discussion started here, and let me tell you some
good news :
The planning is over, we are moving towards a goal now!

Here I will present a short plan of what goals the project has,
please respond back and tell me if you see that we are going in the
same direction. Also note that we are talking about a high level plan
for the next two years here, not something that is done overnight.

The introspector is more than the gcc interface, it is a way of seeing
things, from the inside.

The introspector name is made of two parts :
intro   - inwards, inside
spector - the visualiazion, the viewing, the spying.

This brings us down to the important aspect of the introspector, 
Who is doing the viewing? You are! You are interested in seeing things,
in looking at them, you want to see your programs structures.

Now the inside is simple, you dont want to parse these structures, you
want to see what holds them togeather. You want to get the memory
structures that the authors used themselves.

Here is my proposal for components of the introspector :
Data extraction, manipulation, visualization, and
generation.

1. The ability to extract meta-data from existing programs
this meta data is 
a. what structures are defined in your program
b. what functions are declared and defined
c. which functions use what functions, etc.
d. What are the parameters to this function
e. how is this member used? what happens if I change it.

This will be done by the extraction of the this data from the following
systems :
1.1 gcc tree structures.
1.2 cscc (C# compliler from pnet/dotgnu)
1.3 xml schemas/ xml documents
1.4 perl B::* B::Deparse structure.
1.5 Ruby supports introspector directly
1.7 open c++
1.8 tendra/c compiler
1.9 yacc/bison
1.10 m4 macros
1.11 bash shell scripts
1.12 SQL database structures via The various perl modules for schema
reverse engineering.

2. The ability to manipulate/annotate this meta-data.
People will want to manipulate this data and add information to it.
Therefore the meta data must be in a form that can be edited and
expanded apon. 
Therefore the introspector will produce a standard C API for the
extraction of this meta-data into a DOM data structure. I preferr
libXML to store this. Rdflib from redland gives you even more
structure.
By linking into the lib directly you will be able to get live feeds of
data and do not need to parse xml back in.

3. The ability to limit and select this data.
we need to be able to query the data and extract only needed fields
into a data stream. My Experiments with postgres and mysql show that
they can be used also to store the generic graph structures.

4. The ability to transform this into graphs and layout this data.
We need to be able to annotate the meta-data and provide graph
transformations. Basically you say this thing will be a node, this will
be a edge. You can then also annontate the node with other attributes
you need.
The VCG graph layout tool is my choice for Graph Layout.

5. The ability to edit and print the graphs in UML.
The DIA graph tool is good for the editing of UML graphs. I am working
at this moment on the recompiliation of dia and the studing of its
source.

6. The ability to script any part of this process.
We need to be able to access the memory of the meta-data via a nice api
and then manipulate and query it at any stage of the transformation.
The redland RDF api provides many language bindings to RDF on top of
the libXML. By using this layer, we can provide a standard access to
the needed data. Also if all is kept in memory, we can store native
pointers to the internal data structures for calling functions on the
source of the data.

7. The ability to publish the results,
We need to be able to produce exports to png/gifs as well as many other
programming languages. The Dia toolkit has many of these already and we
can result most of those results.
The platforms we should support are :

1. Debian GNU/Linux
2. Windows Native via the GTK port
3. Cygwin/XWindows 


I look forward to your comments.

Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com