introspector-developers — for anyone interested in hacking the introspector

Re: [Introspector-developers] Can someone compile this

[Gary F. <gar...@js...>]

I don't know if it compiles with the Gnu Java Compiler. It should, it's 
just Java.

Here is leJOS
   http://lejos.sourceforge.net/
the sample ran there.

and

a web site to submit code and get xml back!!! What a great idea. Good 
call Mike :-) (I just wanted an example compiled :-) )

Gary

James Michael DuPont wrote:
> OK, do you know if this will compile with the Gnu Java Compiler?
> http://rcxtools.sourceforge.net/e_home.html
> 
> I will look into this, and that is a good point.
> we need to have a testing service! Let me try this out.
> 
> Good call Gary!
> 
> mike
> --- Gary Frederick <gar...@js...> wrote:
> 
>>Howdy,
>>
>>I just found out about this project and it looks like a winner!
>>
>>I will not have a chance to build the gnu tools to use introspector
>>but
>>would like to see what the XML looks like. I plan on using it to
>>output
>>XML in the form I need for my project.
>>
>>Could someone compile the Java source below and send me the XML out?
>>
>>If I have some XML I can see if I can translate to my XML. Then I
>>would 
>>like to talk about doing that with introspector in general and talk 
>>about adding rdf.
>>
>>Thanks,
>>
>>Gary
>>
>>This is an example of some Java that would be compiled and loaded
>>into a
>>Lego Mindstorms RCX robot. The bb library is the RCX Big Block
>>library
>>in Java.
>>
>>
>>import josx.platform.rcx.Motor;
>>import josx.platform.rcx.Sound;
>>import bb;
>>
>>public class box {
>>    public static void main(String[] args) throws
>>InterruptedException
>>    {
>>      for (myIx = 0, myIx < 4, myIx++) {
>>        bb_Forward(A C 100);
>>        bb_TurnLeft(A C 75);
>>      }
>>    }
>>}
> 
> 
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> _______________________________________________
> Introspector-developers mailing list
> Int...@li...
> https://lists.sourceforge.net/lists/listinfo/introspector-developers

Re: [Introspector-developers] Can someone compile this

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

OK, do you know if this will compile with the Gnu Java Compiler?
http://rcxtools.sourceforge.net/e_home.html

I will look into this, and that is a good point.
we need to have a testing service! Let me try this out.

Good call Gary!

mike
--- Gary Frederick <gar...@js...> wrote:
> Howdy,
> 
> I just found out about this project and it looks like a winner!
> 
> I will not have a chance to build the gnu tools to use introspector
> but
> would like to see what the XML looks like. I plan on using it to
> output
> XML in the form I need for my project.
> 
> Could someone compile the Java source below and send me the XML out?
> 
> If I have some XML I can see if I can translate to my XML. Then I
> would 
> like to talk about doing that with introspector in general and talk 
> about adding rdf.
> 
> Thanks,
> 
> Gary
> 
> This is an example of some Java that would be compiled and loaded
> into a
> Lego Mindstorms RCX robot. The bb library is the RCX Big Block
> library
> in Java.
> 
> 
> import josx.platform.rcx.Motor;
> import josx.platform.rcx.Sound;
> import bb;
> 
> public class box {
>     public static void main(String[] args) throws
> InterruptedException
>     {
>       for (myIx = 0, myIx < 4, myIx++) {
>         bb_Forward(A C 100);
>         bb_TurnLeft(A C 75);
>       }
>     }
> }


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Can someone compile this

[Gary F. <gar...@js...>]

Howdy,

I just found out about this project and it looks like a winner!

I will not have a chance to build the gnu tools to use introspector but
would like to see what the XML looks like. I plan on using it to output
XML in the form I need for my project.

Could someone compile the Java source below and send me the XML out?

If I have some XML I can see if I can translate to my XML. Then I would 
like to talk about doing that with introspector in general and talk 
about adding rdf.

Thanks,

Gary

This is an example of some Java that would be compiled and loaded into a
Lego Mindstorms RCX robot. The bb library is the RCX Big Block library
in Java.


import josx.platform.rcx.Motor;
import josx.platform.rcx.Sound;
import bb;

public class box {
    public static void main(String[] args) throws InterruptedException
    {
      for (myIx = 0, myIx < 4, myIx++) {
        bb_Forward(A C 100);
        bb_TurnLeft(A C 75);
      }
    }
}

[Introspector-developers] Fwd: RFC : Proposal for new simple GTK2-based DIA API [was Re: Dia Python]

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

dear fellow hackers,

you will find my proposal for a new GUI api that uses the redland model
as its basis. 

This will involve a new mixture of gtk2, inline, and swig to try and
create a single definition and support multiple interfaces. 

I think that dajobe is on the right track with swig, and that should be
expanded apon to support the new gtk2 interfaces. Inline has been
experimental support of Swig. The next set is to layout a set of rules
for creating a standard gnome-like scripting api. 

mike

--- James Michael DuPont <mdu...@ya...> wrote:
> From: James Michael DuPont <mdu...@ya...>
> Subject: RFC : Proposal for new simple GTK2-based DIA API [was Re:
> Dia Python]
> To: dia...@gn...
> List-Subscribe: <http://mail.gnome.org/mailman/listinfo/dia-list>,
> List-Archive: <http://mail.gnome.org/archives/dia-list/>
> Date: Thu, 16 Jan 2003 22:25:50 -0800 (PST)
> Content-Length: 1959
> 
> 
> --- Hans Breuer <Ha...@Br...> wrote:
> 
> > >If there's also a perl plugin coming up, we'll
> > >need to encapsulate these things differently, so they behave the
> > same
> > >between main program and plugins.
> > >
> > There is nothing which can be done in Perl which can not be done
> > in Python but readable. Not to start language wars but do we
> > really need another language binding if we lack resources to 
> > maintain one?
> 
> yes we lack resources, but not will power. 
> 
> > 
> > So many people with bright ideas, so many vapor ware ...
> 
> Yes hans, almost all of my ideas about DIA are vapor right now.
> 
> This is directly related to the work I have been putting into the gcc
> interface. We have just released a version for testing 
> http://freshmeat.net/projects/introspector/
> 
> The issue of bindings is difficult, but in the end after some
> discussion, I have come up with the following idea, please comment.
> 
> 1. OAF/Bonobo : this is a fat API that supports costs more than we
> need
> for scripting and interprocess communication.
> 
> 2. GObject2 / GTK : this is the interface we need to script, and
> we can base those scripting interfaces on a standard. For example the
> GTK2 has a set of perl bindings in the works
> http://sourceforge.net/projects/gtk2-perl/
> 
> I think that the best way forward is to define a new API for dia,
> and then start factoring the code from the app back underneath it.
> 
> Here are the classes that i would like to see :
> 
> 1. application
> 2. diagram
> 3. element
> 4. connection
> 
> each of them will support the idea of multiple views, and
> controllers.
> each class will be derived from a "viewable" object and
> "controllable"
> object. They will be responsable for the updating of the views
> attached, and the dispatching of the changes, and the undoing.
> 
> and with "types"
> 
> 1. application type
> 2. diagram type
> 3. element type
> 4. connection type
> 
> each type will allow a specialization of dias behaviour and the
> subclassing of the application would allow for new versions of dia to
> be  created. 
> The types can of course be dynamic, and just support the ability to
> save themselves to a file. So you can create a "prototype" out of an
> instance, by drawing a element, and then converting that to a type. 
> 
> with the major relationships
> application has collection of diagrams
> 
> diagram     has collection of elements
> diagram     has collection of connections
> 
> connection  has a two elements
> connection-class has many instances, each pointing back
> 
> element     has a collection of connections
> element     has a indirect collection of other elements associated
> element-class has many instances, each pointing back
> 
> a view has many objects (applications diagrams, elements,
> connections)
> that are displayed.
> a controller is connected to a object and dispatches messages to them
> a message can be applied and undone. The resulting change to the
> object
> can be undone my a memozation of the objects state before the change
> was made.
> 
> the next step will be to allow this data to be accessed via the
> redland/raptor api. That will also get a similar API as the system.
> Then you can directly query the dataset via the rdf model.
> 
> In fact, the dia model translates directly onto rdf, where a
> connection
> becomes a statement in rdf. 
> 
> These simple interfaces would be contain all the code from the GUI
> that is needed to do all the work.
> 
> I think that they can be derived from the redland model, and that
> will
> be the place that i will start converting to GTK2/GObject2 it
> supports
> SWIG and via the swig we can generate a new set of bindings that
> support a standard based API.
> 
> When the API is finished, i can then present it to you, and we can
> start cutting out the code from DIA and shifting it into this new
> model.
> 
> what do you think?
> mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> _______________________________________________
> Dia-list mailing list
> Dia...@gn...
> http://mail.gnome.org/mailman/listinfo/dia-list
> FAQ at http://www.lysator.liu.se/~alla/dia/faq.html
> Main page at http://www.lysator.liu.se/~alla/dia
> 


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] starting of the reformating of the directories

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

dear all,
this is not much of an announcment,
but i have started to clean up the perl code and make a proper
directory structure!

so the new dirs will be for now (they might be cleaned up again)

./DOCS

# the scripts, they are not installed yet
./bin

# the gcc interface
./c_files
./c_files/cp
./c_files/java

# all the tests
./t
./t/*
./t/input    # moved these two into tests
./t/output   # moved these two into tests

# all the perl stuff goes in here
./lib
./lib/Introspector
./lib/Introspector/database
./lib/Introspector/database/queries
./lib/Introspector/database/SQL
./lib/Introspector/GCC
./lib/Introspector/Redland
./lib/XMLParser
./lib/B
./lib/Class
./lib/introspector

# debian stuff
./debian


I have gotten the installer to work now,
so here is what it installs,
not that it works yet. but for the curious :)

here is a deb :
http://introspector.sourceforge.net/debian/incoming/libintrospector-perl_0.04-1_i386.deb

from that i created an alien :
here is a tgz :
http://introspector.sourceforge.net/alien/tgz/libintrospector-perl_0.04-1.tar.gz

here is an rpm: 
http://introspector.sourceforge.net/alien/rpm/libintrospector-perl-0.04-2.i386.rpm



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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Fwd: [fmII] GCC Introspector 0.4 Alpha Release released ( branch)

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

please all,
can you test this version? 
and vote on the freshmeat how great it is!

--- no...@fr... wrote:
> Subject: [fmII] GCC Introspector 0.4 Alpha Release released ( branch)
> Date: Wed, 15 Jan 2003 09:52:52 -0800 (PST)
> Content-Length: 742
> 
> This email is to inform you of release '0.4 Alpha Release' of 'GCC
> Introspector' through freshmeat.net. All URLs and other useful
> information
> can be found at http://freshmeat.net/projects/introspector/
> 
> The changes in this release are as follows:
> This release has support for GCC 3.2 and the Redland RDF application
> framework. The source has been cleaned up.
> 
> Project description:
> The GCC XML Tree Node Introspector project consists of a patch to the
> gcc compiler to output the internal compiler tree nodes in RDF/XML
> and programs to process that RDF/XML. The tree nodes are complex data
> structures which represent the source code inside the compiler.
> Through these tree nodes, users are able to extract information from
> their programs that would be otherwise very difficult to obtain.
> Modules exist to store these nodes in XML or in a PostgresSQL
> database. The long-term goal of the project is create a high-level
> API that will make the programmatic manipulation of programs easier
> than it is now. 

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] Re: Redland/Raptor issue solved

[Bernardi M. L. <mar...@in...>]

> And  for raptor issues :
> re...@ya...
> http://groups.yahoo.com/group/redland/
> 
> the current issue : ah yes 
> 
> that is the change in the interator ;
> in the new system you use
> http://www.redland.opensource.ac.uk/docs/pod/RDF/Redland/Iterator.html
> 
> my $iterator=$model->targets_iterator($source_node, $arc_node);
>   while($iterator && !$iterator->end) {
>     my $node=$iterator->current;
>     ...
>     $iterator->next;
>   }
> 
> in the older you use 
> i next just next, and that returns the current 
> iirc : 
> my $iterator=$model->targets_iterator($source_node, $arc_node);
>   while (defined($x))
>   {
>    $x  =   $iterator->next;
>   }

> > give me an error on swig processing. It says there is a syntax error
> 

Okey , the issue is resolved , perl interface for redland wants a recent
swig version. I've compiled it fine with 1.3.15. 
Thanks to dajobe on #rdfig.

Cheers,
Mario L. Bernardi

[Introspector-developers] Re: Redland/Raptor problem

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

mario,
please post this also to the mailling list :)
I hope you dont mind that i forward your mail.

And  for raptor issues :
re...@ya...
http://groups.yahoo.com/group/redland/

the current issue : ah yes 

that is the change in the interator ;
in the new system you use
http://www.redland.opensource.ac.uk/docs/pod/RDF/Redland/Iterator.html

my $iterator=$model->targets_iterator($source_node, $arc_node);
  while($iterator && !$iterator->end) {
    my $node=$iterator->current;
    ...
    $iterator->next;
  }

in the older you use 
i next just next, and that returns the current 
iirc : 
my $iterator=$model->targets_iterator($source_node, $arc_node);
  while (defined($x))
  {
   $x  =   $iterator->next;
  }
I cannot acces the cvs web, so i cannot tell you right now how i did
it.

--- Bernardi Mario Luca <mar...@in...> wrote:
> Hi mike , 
> i'm having some problems with RDF_Stats & redland.
> In the handler package you have used ->current() method that belong
> only
> to the cvs version of redland. 

> I've compiled the cvs version lib with success but the perl interface
> give me an error on swig processing. It says there is a syntax error
> on
> Redland.i. 

Hmm... i did not reprocess the swig, just used the code in there.

> I've swig 1.3.10 , do you know there are some issues ( i
> must
> use a particular version ) ? What version you have for redland?

I used cvs head. But oh god, i hope that this is not the mixed up cvs +
release version that i have been testing with!

> I'll also ask this question on redland irc channel.
ok

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Request for comment for a standard DOM based API

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

you can see the newest feature request here,
it is not fully fleshed out, but on the right track.
http://sourceforge.net/tracker/index.php?func=detail&aid=668356&group_id=19878&atid=369878

Please review and comment

Proposal : Create an XML DOM model of the introspector

The RDF data sources used by the introspector are good
for the transfer of data out of the compiler. The
network of nodes stored internally is mapped onto a
network of object externally.

The user of this data is confused by some of the
semantics of the model. Many objects like names and
identifiers that are contained by others are
"pointed-to" by arcs in the graph.
This makes usage of the data mode complex.

I proposed therefore to create a set of transformations
that will create an XML DOM interface for the
introspectors RDF data.

This interface will allow the creation of a TREE
structure out of the network of data for a given
viewpoint. Once in this structure, the DOM can be
translated into a different interface, or serialized
out into XML and loaded into a Browser.

The DOM supports many programming language bindings,
many more than RDF.

The DOM supports named and ordered hierarchies of
collections, the RDF has limited support for collections.

We will define a set of predicates that will be used to
annotate existing RDF predicates of existing rdf files.

The mapping of a RDF onto the DOM will occur by a set
of aggregation , composition and association
relationships that are layered into a hierarchy. The
creation of attributes will also be approched.

We will defined the predicate in a different note.
The predicates will be based on UML and be based on the
previous work in the field (see the end of this for a
list of links)

Association : ObjectA is-associated-with ObjectB
arity of the association- right now we are only
modelling binary associations, not n-ary ones.
We then have two association_ends for an association,
the A and the B end.

Here is the description of the attributes for an
association end.
association_end
{
aggregation - is this a aggregation, collection or
something else (this is als)
ordering - is the order important
qualifier (a list of attributes for finding objects
in the association)
cardinality - what is the minimum and maximum card
of the relationship
navigability - is it possible to navigate this
relationship
navigability-attributes (a list of attributes that
are used to navigate this
association class - do we create an intermediate
class to handle the association? what is the
implementation of the association
}

There are two important subclasses of an association
aggregation and composition.

aggregation is a form of association
{
a whole-part binary relationship between two classes.
}

composition is a form of aggregatoin
{
an object may only by part of one composition
if the parent is destroyed, the the child is destroyed.
}

see also :
http://www.w3.org/TR/NOTE-rdf-uml/
http://www-db.stanford.edu/~melnik/rdf/uml/ 


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] alpha release 0.4

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

dear introspectors,
please do test this version,
it does not have an install yet.
just unpack and run ./intrspctr.pl to generate the code from the
meta-model.

http://introspector.sourceforge.net/debian/incoming/libintrospector-perl_0.04-1.tar.gz
1.5mb

mike


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Forwared message from CraigP:

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

This is a message from craigp98072 posted to the forum
https://sourceforge.net/forum/message.php?msg_id=1795939

Please do send mails to the mailling list, that is reviewed by many
more people.

My response is at the end:

By: craigp98072 ( craigp ) 
 Introspection Toolkits, RMS, and the GPL   
2002-12-15 22:10  
Hello - 

I've been investigating reflective toolkits on and off for the last few
years (such as OpenC++). Just recently I came across GCC-XML and PDT at
http://www.cs.uoregon.edu/research/paracomp/pdtoolkit/. 

In brief, PDT uses the EDG front-end to generate IL, which is then
converted to a human-readable PDB format. They have a reflective API
(called DUCTAPE) which processes these PDB files. The EDG compiler is
nearly ANSI-C++ compliant, and so is much better than home-grown C++
compilers like that used for OpenC++ (which doesn't handle templates
very well). 

So one question I have: how much will this project be focused on C++?
It looks like you want to support several languages, like C, Java, and
Perl. Will you have full support for C++ templates? 

I'm looking to get involved in one of these projects. I've corresponded
(briefly) with RMS about patching GCC to do similar things you are
doing (creating a reflexive API/MOP), but he was strongly opposed to
the idea (without providing a cogent, or really any, argument to
support his position). So I'm hesitant to join a project which is
opposed by RMS and/or the FSF, and simultaneously comes burdened with
the GPL (PDT is completely free). Are you creating a library/toolkit?
If so, are you considering using the LGPL, which is a much more open
license? 

I'd appreciate thoughts anyone has on this matter. 

thanks! 
--craig  

My response :
-----------------------------------------------------------------
>>Are you creating a library/toolkit?
yes we are, but as part of a full application.

>>In brief, PDT uses the EDG front-end to generate IL, which is then
>>converted to a human-readable PDB format
IL, you mean Dot.NET Microsoft IL? 
djbarker is working with EDG. I hope that he will respond :)

>>If so, are you considering using the LGPL, which is a much more open
>>license? 
not yet. The idea is to create an framework of similarly licensed tools
that perform tasks. Just making an API is good, but we need to provide
tools as well.

>>In brief, PDT uses the EDG front-end to generate IL, which is then
>>converted to a human-readable PDB format
THe 

>>So one question I have: how much will this project be focused on C++?

C++ is one target language we are supporting.

>>It looks like you want to support several languages, like C, Java,
and Perl. Will you have full support for C++ templates? 

yes we should support full templates.

>>I'm looking to get involved in one of these projects. 
Please do get involved in the introspector!

>>So I'm hesitant to join a project which is opposed by RMS and/or the
FSF
RMS does like any external APIs into free tools. That is becuase the
GPL is based on copyright. Copyright cannot protect intermediate files
from being reverse engineered.
I have decided just to ignore thier worries. If we put all the tools
onto the same license as the gcc, using GPL, then it is not our
problem. 

>> and simultaneously comes burdened with the GPL (PDT is completely 
>> free). 
The GPL is because we are building tools into GPLed tools. What should
an API into the gcc have a license that is not GPL? 

After I met with RMS in berlin last year, we aggreed that the best way
forward is to provide functionality for the end user. The intermediate
files are not the goal, but a means. The whole idea of the introspector
is to in the end provide a GUI, and interface to emacs, and a whole
range of developer tools. To do that, we need to have a cohesive set of
tools that all have the same license. 

The EDG toolkit is also being looked into 

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] The start of the detailed specification phase

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

Dear all,

I have started to put the specs for the new api of the introspector 
onto a public place 

https://sourceforge.net/tracker/?func=browse&group_id=19878&atid=369878

Here you will see the following 
This is an older file, was stored in the API.txt in cvs. 
https://sourceforge.net/tracker/index.php?func=detail&aid=667654&group_id=19878&atid=369878
It talkes about a basic set of functions for the introspector nodes,
the idea of a context. A context being the area where an object lives,
its containing structure or environment.

Futhermore, it talks about subjects, functions(predicates) and object.
Each of these are similar to the redland, but impose the idea that each
one will have a declaration and type. 

That means, we should be able to find the point of each object where it
is declared, and what type it is. 

The trace and intercept are basic functionalities needed by the
introspector.


https://sourceforge.net/tracker/index.php?func=detail&aid=667662&group_id=19878&atid=369878

This is the prototype for the collection of the 
function type , parameters type collection

https://sourceforge.net/tracker/index.php?func=detail&aid=667669&group_id=19878&atid=369878

This is the prototype for the collection of the 
fields of a record type


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] introspector meta-logical requirements

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

This is an experimental set of 
something like triples.
I will be posting a newer version, this might be interesting to you.

Splitting-of-module-up-into-new-modules 	is-a requirement
creation-of-tools-to-refactor-code  		is-a requirement
extraction-of-variables-and-dependancies	is-a requirement
finding-of-the-scope-of-a-variable		is-a requirement
Finding-all-the-usages-of-a-variable 		is-a requirement
regeneration-of-source-code			is-a requirement
translation-of-source-code-into-new-language	is-a requirement
Replacing-expressions-with-other-expressions 	is-a requirement
editing-of-source-in-memory     		is-a requirement
Treat-data-as-RDF-triples 			is-a requirement
visualizing-of-sections-of-code 		is-a requirement

STATEMENT-AS-A-NODE 		IS-A 		  RULE
STATEMENT-AS-A-NODE-BREAKDOWN 	NAME 	          BREAKDOWN
STATEMENT-AS-A-NODE-BREAKDOWN 	OPERATION-Comment "a statement-as-a-Node
can be broken down into statement"
STATEMENT-AS-A-NODE-CREATE 	RANGE	  	  STATEMENT-AS-A-NODE
STATEMENT-AS-A-NODE-CREATE 	DOMAIN	  	  STATEMENT

STATEMENT-AS-A-NODE 		OPERATION 	  STATEMENT-AS-A-NODE-CREATE
STATEMENT-AS-A-NODE-CREATE	NAME 	  	  CREATE
STATEMENT-AS-A-NODE-CREATE	is-a 	  	  OPERATION
STATEMENT-AS-A-NODE-CREATE 	DOMAIN	  	  STATEMENT-AS-A-NODE
STATEMENT-AS-A-NODE-CREATE 	RANGE	  	  STATEMENT
STATEMENT-AS-A-NODE 		OPERATION-Comment "a statement-as-a-Node can be
created out of a statement"


STATEMENT-AS-A-NODE-CREATE      is-inverse-of   
STATEMENT-AS-A-NODE-BREAKDOWN

is-inverse-of			is-a 	relationship
is-inverse-of			domain 	RULE
is-inverse-of			range 	RULE
is-inverse-of			description 	"when a rule is the inverse of a another"

IMPLIES			is-a   relationship
IMPLIES			domain 	RULE
IMPLIES			range 	RULE
IMPLIES			description 	"when a rule implies another"


STATEMENT			AS-A NODE
AS-A				is-a representation
STATEMENT-BECAUSE-STATEMENT 	is-a RULE
STATEMENT-IMPLIES-STATEMENT     is-a RULE
STATEMENT  BECAUSE STATEMENT
STATEMENT  IMPLIES STATEMENT


recompile-times-are-large       is-a                  statement
editing-of-source-in-memory	BECAUSE              
recompile-times-are-large
recompile-times-are-large       IMPLIES              
editing-of-source-in-memory	
editing-of-source-in-memory	is-a                  requirement
editing-of-source-in-memory	about                 source
editing-of-source-in-memory	defined-operation     editing
editing-of-source-in-memory	defined-operation-on  source
editing-of-source-in-memory	defined-operation-in  memory
source                          is-stored-in          memory

Splitting-of-module-up-into-new-modules is-a requirement
	file is-a storage
	module is-a file
	file is-a resource
	

Replacing-expressions-with-other-expressions is-a requirement
	replace-expression is-a      use-case	
	replace-expression range     database
	replace-expression domain    database
	replace-expression parameter expression-to-find
	replace-expression parameter expression-to-replace-with

Finding-all-the-usages-of-a-variable is-a requirement
	find-usage-of-variable is-a use-case
	usage-of-variable      is-a use-case
	variable               is-a object
	

visualizing-of-sections-of-code is-a requirement
      code-section  is-a       section
	section     is-a       subset
	section     is-a       range
      code-section  contains   code
	code	 has-operation visualize
	visualize   is-a       output-operation
  output-operation  has-a      output-context
    output-context  is-a       context
  	 operation  has-a      context
  output-operation  has-a      output-format
  	 operation  has-a      state


	code	    represents program-knowledge
	data        output-as  gui-records
	data        output-as  gui-list
	data        output-as  gui-tables 
	data        output-as  gui-trees
	data        output-as  gui-graphs
	gui-records displays   records
	gui-list    displays   list
	gui-tables  displays   tables
	gui-trees   displays   trees
	gui-graphs  displays   graphs
	graph       has-method layout


Treat-data-as-RDF-triples is-a requirement
	database stores program-knowledge
	program-knowledge is program-data
	data is-defined-as program-data
	data is-defined-as instance-data-structures
	data is-defined-as objects

	instance-data-structure should-be-able-to
serialize-itself-into-triples-format.
	serialize-itself-into-triples-format is-a method
	serialize-itself-into-triples-format has-range triples-format
	serialize-itself-into-triples-format has-domain
instance-data-structure
	triples-format is-a set-of-statements
	set-of-statements contains statements
	statements are-a-collection-of statement
	statement has-a subject
	statement has-a predicate	
	statement has-a object
	subject   is-a node
	object    is-a node
	predicate is-a node
	predicate is-a property

	each is-a qualifier 
	instance-data-structure	 is-a object	
	should-be-able-to is-a statement-of-requirements

	statement-of-requirements is-a      statement
	statement-of-requirements is-about  requirements

	requirements is-collection-of requirement
	requirement is-a need
	data-structure has instances
	instances is-collection-of instance
	data-structure has-a type
	type is-a class
	handling of traversal
	context of traversal
	traversal is-a operation on-a collection
	collection has-op traversal
	has-op defined-has operation
	defined-has is-a has
	has is-a property
	has-a is-a property
	is-a is-a property
	iterator is-a operation
	network has iteration-paths
	iteration-paths	is-a-collection-of paths
	iteration-paths	is-result-of iteration
	iteration is-a operation
	iteration operation collection
	iteration instance interator
	paths collection-of path
	vector is-a sequence 
	list   is-a sequence
	path   is-a sequence
	serialize is-a operation
	serialize-itself is-a method
	method is-a operation
	method is-a property


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] CVS update

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

Dear all,
I have removed alot of dead wood and factored the 
testing code into the "t" subdir that is the perl standard.

use "cvs update -P -d" on a clean dir to get the latest version
next we will be splitting off the parts into separate packages
1. postgres database 
2. the code generators
3. the generated code.

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] back to reality

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

ok, you may have been thinking i am going off the deep end.
well, i have caught myself. E-kyle and mario have talked me kindly back
into reality.

But, you might want to check out this :
http://www.stratego-language.org/twiki/bin/view/Stratego

So, major CVS update today. I got lincvs installed, it allows an easy
way to delete directories. I have removed all the generated code from
cvs.

the cvsignore only keeps things from being added,
if they are in the project, you have to remove them, and also it is
best to do a clean checkout.

Here is an overview of the directories and what will happen

TO PUT INTO PROJECT SPECIFIC Directory
all the code that is generated or used to generate will go into
a project directory, sepearate from the core
	input        - the input
	introspector - the output
	output/SQL   - more output	
	output/Java
	output/HTML

GCC INTERFACE :
	c_files
	c_files/cp
	c_files/java

PERL CODE : 
	gcc             - really old interface, will be replaced by rdf
	B               - for perl code extraction (should not be used)
	Class           - older meta-code for perl
	Introspector    - newer stuff

DATABASE CODE:          - this needs to be put into its own project
	database  
	output/SQL
	queries

TESTS :                 - testing code, and tests needs to be
consolidated
	bin
        TOOLS
	T
	TESTS
	TESTS/test_cpp
	TESTS/test_java
	tests
	tests/simple
	tests/xml

TO LEAVE :
	DOCS


TO REMOVE :  -- older stuff not used
	XMLParser
	xsl

REMOVED  :   -- directories not used in the core
	introspector/*
	output/SQL	
	output/Java
	output/HTML


mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] Happy new year, plan for 2003

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

--- Kyle Lahnakoski <ky...@ar...> wrote:
> James Michael DuPont wrote:
> 
>  > The mop interface will be written in a high level language, based
> on
>  > RDFS DAML.
> 
>  From what little I can see DAML+OIL is the only standard relating to
> 
> class definitions (http://www.daml.org/2001/03/daml+oil-index.html). 
> But even this is quite restrictive (class algebras and attribute 
> definitions only).

Well they also support properties, and that is very important. 

The meta-data that we have about about the gcc nodes can be described
with such a ontology. Basically a complete set of all the predicates,
the types of nodes etc.

OWL also supports more methods, and cyc even more. 
cyc :
http://www.daml.org/ontologies/132
owl
http://www.w3.org/TR/2002/WD-owl-ref-20020729/

Ww should be able to define new predicates as need, 
have you any in mind?

> 
>  > I hope to defined  with you a set of predicates that are available
> to
>  > use in a RDF file that can be used as a resource in the future.
>  > Documented and related to other models. The whole trick is to
> produce
>  > files that we can build apon. That is one drawback of the current
> usage
>  > of perl hashes for storage in the introspector, there is too
> little
>  > structure and they are hard to interpret.
>  >
>  >  A set of predicates that are available. Right now that is the
> contents
>  > of the ModifyClasses and the Meta* classes.
> 
> Am I right to assume you are concerned that your existing set of 
> predicates may not be sufficient?  

No, I am concerned that we are covering the same ground as others. 

> Copying CLOS would provide a sense
> of 
> security that the necessary predicates are defined, despite not being
> in 
> use at this time?
I just want to map the clos predicates on to ours, in order to define
our model in terms of clos. We dont need all the clos. 

Because the clos is so mature, we should be able to learn from them,
and also copy needed interfaces that we dont cover yet.

> 
>  > We have that meta-model that is used to describe language
> structures
>  > dealt with. Then we have an instance of that that are extracted by
> the
>  > gcc into the input/types_overview and input/fields_overview and
> the
>  > CreateClasses.  These files define the gcc c,c++,and java model as
> an
>  > instance of a meta model. From there we translate the model into
>  > different languages, perl, java, sql, (treecc) etc. later also
> CLOS.
> 
>  >>Will this standard MOP will take the form of a document that
> humans
>  >>can read?
>  >
>  > yes.
> 
> Then I would be happy to at least start something.  I would prefer a 
> more UML-like notation over DAML/XML.  I am a more visual person than
> textual.

Ok, well, UML is great. I like UML. 
The plan was to export the model into DIA and be able to edit it in DIA
as well. Using VCG as the layout. We are not there yet.

> 
>  >>What language is this all written in?  Perl?
>  >
>  > right now, yet. The whole challenge is to defined a Java and Lisp
> based
>  > interface into this MetaData, and the instance data so that you
> can get
>  > a standard stream of program data from the gcc. What you do with
> it and
>  > how you process it is application specific.
> 
> Oh.  There are two problems Introspector may be solving, please
> indicate 
> which one:
> 
> 1)	If we want an MetaData interface to Java, Lisp, etc, then should
> we 
> just build the prerequisite classes in each that will read the 
> *.ntriples data and provide ability to tour the resulting objects
> (which 
> describe the program structure).  This option is dreadfully simple to
> do, but hard to extend.

Hmm, that is a idea. If you can create new java classes on the fly? 
I guess that is the idea. 

If anyone wants to create a java or lisp implementation that reads the 
rdf files and builds them into an intelligent model in memory, then
please do that. 

> 2)	We make a set of programs (in Perl) that write the MetaData
> interface 
> for each langauge (let's call these programs the "MetaClassWriters").
> 
> The MetaClassWriters are easily extensible because, presumably, they 
> read some common meta-class description.  Ihis version is harder to 
> write because of the meta-programming involved.  You appear to be
> doing 
> this now.
yes, I have a set of classes, JavaGenerator for example that will
output java definitions based on the meta data.

> 
> I am lost as to what the ultimate goal is.  Maybe I stop asking dumb 
> questions if you told me about some example program that would use
> this.

The goal is to provide a simple and easy to use API to the gcc ASTS in
many languages. To create a model of the internals of the compiler in
such a way that we can easily create applications that process them.
the number of applications are enormous. Just look at the different
project that you have SWIG, Doxygen, GCCXML, etc. there are many tools
that need this data, and we can provide it.

That idea is to be expanded also to cover other meta-data like from
Bash, I have been experimenting with bashdb.sf.net it looks like they
cover all the needed information, it should be easy to create an
interface into that.

The introspector as I said should be viewed as a Telephony Switch,
something that you hook your applications up to and you accept calls or
place them. The need is simple, many free software tools need to get at
meta-data, we should provide it.

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] Happy new year, plan for 2003

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

Kyle,
I have been thinking about what you said some more,
and have the following points to add :

the reason why we need to be able to create the structure and the
instances separatly in the different target languages is that it is
very difficult to create a generic reader for the ASts. 

Basically we have a data feed and want to create a generic model of
data from the gcc, in a way that we can process it in various
languages.

From this generic meta-model, we should be able to generate and give
the users a simple set of data structures that they can use to
manipulate the data from the gcc. And we should be able to create
instances of them as static snippets of code, or reading them from rdf
files. 

The usage of reflection is great, but only helps if you have an
instance of the give object, with the right class. 

mike

--- Kyle Lahnakoski <ky...@ar...> wrote:
> 
> I will mostly repeat what you said so that I know I understand.
> 
> James Michael DuPont wrote:
>  > the second step will be to document the meta-model in terms of the
>  > common lisp object system CLOS. it is a well understood model that
> has
>  > well defined semantics. I thik that a CLOSGenerator (Like a
>  > java-generator) is the right way forward.
> 
> CLOS may be very good MOP (Meta-Object Protocol) to copy.  It may be
> too 
> flexible; being needlessly complex to handle situations never used. 
> I 
> really do not know much about the CLOS.
> 
>  > But we need to do one more thing :
>  > Thirdly. all the language generators currently describe classes,
>  > the java generator creates classes. but what about objects?
> 
> I am sure that this is not a problem for CLOS.
> 
> It is not a problem for Java either; the reflection API is sufficient
> to 
> create objects and populate their fields.  We may want to add a
> simple 
> API on top of it for some more-commonly used operations. (assuming 
> anything is even built in Java)
> 
>  > we nee an JavaInstance generator : the ability to create code that
>  > represents instances of java, in terms of the generated classes.
> Also
>  > we need to be able to read in instances from an XML/RDF feed.
> 
> So, I guess you are saying we need a standard MOP, probably like
> CLOS. 
> This standard MOP should be able to handle the majority of languages 
> introspector plans on inspecting.
> 
> Will this standard MOP will take the form of a document that humans
> can 
> read?  Or are we going to have it hidden in implementation code?  :)
> 
>  > so to summarize :
>  >
>  > 1. support the creation of meta-model from the rdf input from the
> gcc.
>  >  : meta-circularity
>  >
>  > 2. support the generation of CLOS classes
>  >  : using a well defined class model to document ours
>  >
>  > 3. support the generation of source code for instances of
>  > Java, perl, CLOS, sql from the rdf, in terms of the generated
> classses.
>  >   : creation of literal source code that creates instances from
> the
>  > literals (constants)
>  >
>  > 4. Support reading of the rdf files and generation of these
> instances
>  > as programm code.
>  >   : creation of source code that creates instances from a variable
> file
>  > of data.
> 
> So introspector plans to:
> 
> 	Read in nodes from gcc
> 	Build an internal representation (functions, and classes)
> 	Serialize to various languages
> 
> In essence we will have a language conversion facility.
> 
> 
> What language is this all written in?  Perl?
> 
> 
> Thanks
> 
> 
> 
>
----------------------------------------------------------------------
> Kyle Lahnakoski                                      
> ky...@ar...
> (416) 892-7784                                    Arcavia Software
> Ltd
> 
> 


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] Happy new year, plan for 2003

[Kyle L. <ky...@ar...>]

James Michael DuPont wrote:

 > The mop interface will be written in a high level language, based on
 > RDFS DAML.

 From what little I can see DAML+OIL is the only standard relating to 
class definitions (http://www.daml.org/2001/03/daml+oil-index.html). 
But even this is quite restrictive (class algebras and attribute 
definitions only).

 > I hope to defined  with you a set of predicates that are available to
 > use in a RDF file that can be used as a resource in the future.
 > Documented and related to other models. The whole trick is to produce
 > files that we can build apon. That is one drawback of the current usage
 > of perl hashes for storage in the introspector, there is too little
 > structure and they are hard to interpret.
 >
 >  A set of predicates that are available. Right now that is the contents
 > of the ModifyClasses and the Meta* classes.

Am I right to assume you are concerned that your existing set of 
predicates may not be sufficient?  Copying CLOS would provide a sense of 
security that the necessary predicates are defined, despite not being in 
use at this time?

 > We have that meta-model that is used to describe language structures
 > dealt with. Then we have an instance of that that are extracted by the
 > gcc into the input/types_overview and input/fields_overview and the
 > CreateClasses.  These files define the gcc c,c++,and java model as an
 > instance of a meta model. From there we translate the model into
 > different languages, perl, java, sql, (treecc) etc. later also CLOS.

 >>Will this standard MOP will take the form of a document that humans
 >>can read?
 >
 > yes.

Then I would be happy to at least start something.  I would prefer a 
more UML-like notation over DAML/XML.  I am a more visual person than 
textual.

 >>What language is this all written in?  Perl?
 >
 > right now, yet. The whole challenge is to defined a Java and Lisp based
 > interface into this MetaData, and the instance data so that you can get
 > a standard stream of program data from the gcc. What you do with it and
 > how you process it is application specific.

Oh.  There are two problems Introspector may be solving, please indicate 
which one:

1)	If we want an MetaData interface to Java, Lisp, etc, then should we 
just build the prerequisite classes in each that will read the 
*.ntriples data and provide ability to tour the resulting objects (which 
describe the program structure).  This option is dreadfully simple to 
do, but hard to extend.
2)	We make a set of programs (in Perl) that write the MetaData interface 
for each langauge (let's call these programs the "MetaClassWriters"). 
The MetaClassWriters are easily extensible because, presumably, they 
read some common meta-class description.  Ihis version is harder to 
write because of the meta-programming involved.  You appear to be doing 
this now.

I am lost as to what the ultimate goal is.  Maybe I stop asking dumb 
questions if you told me about some example program that would use this.







-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                       ky...@ar...
(416) 892-7784                                    Arcavia Software Ltd

Re: [Introspector-developers] Happy new year, plan for 2003

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

--- Kyle Lahnakoski <ky...@ar...> wrote:
> 
> I will mostly repeat what you said so that I know I understand.
> 
> James Michael DuPont wrote:
>  > the second step will be to document the meta-model in terms of the
>  > common lisp object system CLOS. it is a well understood model that
> has
>  > well defined semantics. I thik that a CLOSGenerator (Like a
>  > java-generator) is the right way forward.
> 
> CLOS may be very good MOP (Meta-Object Protocol) to copy.  It may be
> too 
> flexible; being needlessly complex to handle situations never used. 
> I really do not know much about the CLOS.

Well, I am just learning about it myself. We dont need to support all
features,
just the core set of them that we can. 

Classes, members, methods, collections.

The point is the CLOS interface will allow our data to be used in the
world of LISP/AI, and hopefully later even emacs.

By supported a simple CLOS export, we will also document our model to
other people in a language they understand. I think that defining our
model in terms of a more well known model will be easier that defining
our model in isolation.

> 
>  > But we need to do one more thing :
>  > Thirdly. all the language generators currently describe classes,
>  > the java generator creates classes. but what about objects?
> 
> I am sure that this is not a problem for CLOS.
> 
> It is not a problem for Java either; the reflection API is sufficient
> to 
> create objects and populate their fields.  We may want to add a
> simple 
> API on top of it for some more-commonly used operations. (assuming 
> anything is even built in Java)

Good point :

We have a java api generated now. Based on the introspector meta-model
we create classes, methods, members, inheritance and interfaces. 

The collections and containers to handle relationships between
containers and components is next : For example as we chatted about the


> 
>  > we nee an JavaInstance generator : the ability to create code that
>  > represents instances of java, in terms of the generated classes.
> Also
>  > we need to be able to read in instances from an XML/RDF feed.
> 
> So, I guess you are saying we need a standard MOP, probably like
> CLOS. 
> This standard MOP should be able to handle the majority of languages 
> introspector plans on inspecting.

The mop interface will be written in a high level language, based on
RDFS DAML. 

I hope to defined  with you a set of predicates that are avaiable to
use in a RDF file that can be used as a resource in the future.
Documented and related to other models. The whole trick is to produce
files that we can build apon. That is one drawback of the current usage
of perl hashes for storage in the introspector, there is too little
structure and they are hard to interpret.

 A set of predicates that are available. Right now that is the contents
of the ModifyClasses and the Meta* classes. 

We have that meta-model that is used to describe language structures
dealt with. Then we have an instance of that that are extracted by the
gcc into the input/types_overview and input/fields_overview and the
CreateClasses.  These files define the gcc c,c++,and java model as an
instance of a meta model. From there we translate the model into
different languages, perl, java, sql, (treecc) etc. later also CLOS.


Some of the gcc model definition in the type_overview are very hard to
read, they are extracted out of the xml, this will be replaced by the
rdf reader, so we can specify the class model in a C++ file and extract
it into rdf via the introspector.


> 
> Will this standard MOP will take the form of a document that humans
> can 
> read? 

yes. 

> Or are we going to have it hidden in implementation code?  :)
> 
>  > so to summarize :
>  >
>  > 1. support the creation of meta-model from the rdf input from the
> gcc.
>  >  : meta-circularity
>  >
>  > 2. support the generation of CLOS classes
>  >  : using a well defined class model to document ours
>  >
>  > 3. support the generation of source code for instances of
>  > Java, perl, CLOS, sql from the rdf, in terms of the generated
> classses.
>  >   : creation of literal source code that creates instances from
> the
>  > literals (constants)
>  >
>  > 4. Support reading of the rdf files and generation of these
> instances
>  > as programm code.
>  >   : creation of source code that creates instances from a variable
> file
>  > of data.
> 
> So introspector plans to:
> 
> 	Read in nodes from gcc
> 	Build an internal representation (functions, and classes)

> 	Serialize to various languages

yes, that is *ONE* major application of the introspector,
other people dont want to serialize, but to do analysis of the nodes.

so that looks like :
* 	Read in nodes from gcc
* 	Build an new internal representation (nodes and edges in a graph)
* 	Apply graph transformations
*       Generate reports.

or even :
* 	Read in nodes from gcc
* 	Build an new internal representation (nodes and edges in a graph)
* 	Apply graph transformations
*       Run nodes via graph layout tool VCG
*       Generate UML nodes in DIA
*       Export data into emacs
*       insert click handler in dia to open up emacs


> 
> In essence we will have a language conversion facility.
yes at the lowest level.
> 
> 
> What language is this all written in?  Perl?
right now, yet. The whole challenge is to defined a Java and Lisp based
interface into this MetaData, and the instance data so that you can get
a standard stream of program data from the gcc. What you do with it and
how you process it is application specific.

for the building of the framework, yes, language transformations are
important. But that is just one step of many.

mike
> 
> 
> Thanks
> 
> 
> 
>
----------------------------------------------------------------------
> Kyle Lahnakoski                                      
> ky...@ar...
> (416) 892-7784                                    Arcavia Software
> Ltd
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Introspector-developers mailing list
> Int...@li...
> https://lists.sourceforge.net/lists/listinfo/introspector-developers


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] Happy new year, plan for 2003

[Kyle L. <ky...@ar...>]

I will mostly repeat what you said so that I know I understand.

James Michael DuPont wrote:
 > the second step will be to document the meta-model in terms of the
 > common lisp object system CLOS. it is a well understood model that has
 > well defined semantics. I thik that a CLOSGenerator (Like a
 > java-generator) is the right way forward.

CLOS may be very good MOP (Meta-Object Protocol) to copy.  It may be too 
flexible; being needlessly complex to handle situations never used.  I 
really do not know much about the CLOS.

 > But we need to do one more thing :
 > Thirdly. all the language generators currently describe classes,
 > the java generator creates classes. but what about objects?

I am sure that this is not a problem for CLOS.

It is not a problem for Java either; the reflection API is sufficient to 
create objects and populate their fields.  We may want to add a simple 
API on top of it for some more-commonly used operations. (assuming 
anything is even built in Java)

 > we nee an JavaInstance generator : the ability to create code that
 > represents instances of java, in terms of the generated classes. Also
 > we need to be able to read in instances from an XML/RDF feed.

So, I guess you are saying we need a standard MOP, probably like CLOS. 
This standard MOP should be able to handle the majority of languages 
introspector plans on inspecting.

Will this standard MOP will take the form of a document that humans can 
read?  Or are we going to have it hidden in implementation code?  :)

 > so to summarize :
 >
 > 1. support the creation of meta-model from the rdf input from the gcc.
 >  : meta-circularity
 >
 > 2. support the generation of CLOS classes
 >  : using a well defined class model to document ours
 >
 > 3. support the generation of source code for instances of
 > Java, perl, CLOS, sql from the rdf, in terms of the generated classses.
 >   : creation of literal source code that creates instances from the
 > literals (constants)
 >
 > 4. Support reading of the rdf files and generation of these instances
 > as programm code.
 >   : creation of source code that creates instances from a variable file
 > of data.

So introspector plans to:

	Read in nodes from gcc
	Build an internal representation (functions, and classes)
	Serialize to various languages

In essence we will have a language conversion facility.


What language is this all written in?  Perl?


Thanks



----------------------------------------------------------------------
Kyle Lahnakoski                                       ky...@ar...
(416) 892-7784                                    Arcavia Software Ltd

[Introspector-developers] Happy new year, plan for 2003

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

Dear fellow hackers,

Happy new year!
2003 is a new year, and an important year for the introspector.

Thank you all for your support and ideas, we are getting close to a
major breakthrough.

What we need in this project is a clean goal, one that we can all work
towards. Something that is clearly stated. Something that we can all
agree on.

here is my attempt : please tell me what you think

The next major milestone of the introspector is to read in structures
and fields, classes and members from c/c++ and java into the
meta-model. 

We will read in the rdf and instanciate the classes and members from
the ModifyClasses.pm as used in the CreateClasses.pm

this will allow us to read in any C/C++/Java code and then generate
Perl,SQL, html and Java code from it. it will allow us to use the
introspector for static modelling.


the second step will be to document the meta-model in terms of the
common lisp object system CLOS. it is a well understood model that has
well defined semantics. I thik that a CLOSGenerator (Like a
java-generator) is the right way forward.

But we need to do one more thing :
Thirdly. all the language generators currently describe classes,
the java generator creates classes. but what about objects?


we nee an JavaInstance generator : the ability to create code that
represents instances of java, in terms of the generated classes. Also
we need to be able to read in instances from an XML/RDF feed. 

so to summarize :

1. support the creation of meta-model from the rdf input from the gcc.
 : meta-circularity

2. support the generation of CLOS classes
 : using a well defined class model to document ours

3. support the generation of source code for instances of 
Java, perl, CLOS, sql from the rdf, in terms of the generated classses.
  : creation of literal source code that creates instances from the
literals (constants)

4. Support reading of the rdf files and generation of these instances
as programm code.
  : creation of source code that creates instances from a variable file
of data.

so we have a clear roadmap. Right now we have over 20 members of the
mailing list, many are interested, but are not active. We have 9
project members, but only 2-3 are active. It time to bring some clean
targets and goals into the project and find people who are interested
in helping or that think that we are working in the right direction.

Regards,
mike



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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] Merry Christmas

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

Dear Fellow hackers,

I just wanted to wish you all a merry Christmas and  the best for 2003.

I will be away, and this time I am only taking a couple of books with
me, so no hacking over christmas!

Next year will be an important year for the introspector project!

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Introspector-developers] RDF_Stats.pl

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

Dear fellow hackers,

The first stone is layed down, I now have a working version of the
redland/raptor cvs version, it seems that there were some minor issues
with perl 5.8 that needed addressing. Dajobe has provided excellent
support and help fix and find all the problems.

I have committed the RDF_Stats.pl, a program that will extract the
statistics of a ntriples file, and tell you what types of nodes are
used.

It reads a n3 file, that you can create from a rdf file with rdfdump
eg:
 rdfdump -o ntriples file:test.rdf

Then it produces a statistic of how often a uri is used as a predicate,
object or subject in an rdf file.
the output is in rdf, of all things, just as a test. 

this is the first step in creating a daml outputter for the
introspector, where we will be outputting the meta-model in daml.
 
here is a sample output of the opencyc data base ran through this
program :
  <rdf:Description
rdf:about="http://www.daml.org/2001/03/daml+oil#Restriction">
    <ns0:count-objects
xmlns:ns0="http://introspector.sourceforge.net/2002/12/22/stats.daml#">11</ns0:count-objects>
  </rdf:Description>
  <rdf:Description
rdf:about="http://www.daml.org/2001/03/daml+oil#Restriction">
    <ns0:count-subject
xmlns:ns0="http://introspector.sourceforge.net/2002/12/22/stats.daml#">4</ns0:count-subject>
  </rdf:Description>

here you see that a
you run the program like this: 
perl ./RDF_Stats.pl stats.n3 stats.rdf
it reads in the n3 input file from the first parametere, and produces
an rdf output file based on the second parameter.

The output looks like this
the counts for object, subject or predicate are stored in their own
predicate :
http://introspector.sourceforge.net/2002/12/22/stats.daml#count-objects
http://introspector.sourceforge.net/2002/12/22/stats.daml#count-subject
http://introspector.sourceforge.net/2002/12/22/stats.daml#count-predicates

so you have the uri as the subject, the count predicate and the the
count as a subject.

Later on, I will be adding more features like :

1. extraction of the commonly used number of properties that an subject
has. 
2. Deterimining the statistics of an URI, does a predicate always have
a different object, the same object or is there a fixed number of
objects that have a certain frequency.
3. Is there a field that is a key, that all objects have in common, or
is there a mutually exclusive set of fields(predicates) that we can
look for all the objects that have that, and we will find each subject
only once. Put simply, is there a primary key or a set of primary key
fields for accessing all the objects?
4. Can we treat a give object as being dependant on another, or is it
used/referenced by multiple objects. For each predicate we will try and
determine the cardinality of the relationships defined by a predicate :
are they associations, aggregation or composition? Are the 1-1,
(0:1)-(1), m-n, 1-m etc.

Anyway, I hope to create a set of debs soon that contain all the
binaries needed to run this, with a redland cvs snapshot and the gcc
shaptshot. We need to package what we have now, becuase it is good and
working.

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] current status

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

--- "cr...@is..." <cr...@is...> wrote:
> On Sat, 21 Dec 2002, James Michael DuPont wrote:
> 
> > hey craig,
> > thanks for writing. Come and visit us on the #introspector
> > irc.openprojects.net for a chat.
> 
> Email is my preferred communication medium, but I'll consider getting
> an
> IRC client (folks on the schmoo and a couple other lists wanted to
> chat
> via IRC as well; I guess I'm just not the chatty type :-/).

:) thats ok. 

> 
> Note that I'm going to be celebrating Yule/Winter Solstice for most
> of
> this weekend.  After that I should have some time over the holidays.

sure, i will also be offline next week. Happy holidays!


> 
> > > Hey -
> > >
> > > I've been looking at this and gccxml. It's a little hard for me
> to
> > > figure out what the current status of this project is. Will this
> work
> > > on win32?
> 
> > yes it will, with cygwin, i have been testing with the 3.2, but the
> > berkley db support of redland is not dont on win32.
> 
> I don't know much about redland or RDF (tho I know a bit about XML
> Schema).
The redland is a application framework, We replaced all the printf with
it.

> Can we use mysql rather than berkely db, or is redland
> itself not
> ported to win32? 
I have ported it without any real problems, have also tested the patch
on cygwin, and debian

> I did not see cygwin listed on redland's site.
> 
> Do you currently serialize the parse tree in binary format, or do you
> only
> write it out to xml/rdf? 
Redland supports a binary format, using bdb, and also other storages. 
There is also the tree serializer branch of the gcc.

> Does it make sense to use binary format? 
> Was
> part
> of the vision to allow arbitrary modification of the parse tree
> during
> compilation, and if so, would that require converting the xml/rdf
> back to
> binary format for gcc to process? 
good question. Yes we want to support that, a two way interface between
redland and the gcc. I figure we can store a native pointer to the node
int the redland object, and then have an application layer that can
call methods on a redland node that is a proxy to a gcc. 

As far as reflection, there are some reflection libs for c++,
eg http://www.garret.ru/~knizhnik/cppreflection/docs/reflect.html
but they still need data input. I figure we need to add in some
built-in functions into gcc that can give you access to the trees. 
like the typeof operator, or a class lib. 
You might want to take a look at an older effort of mine to wrap the
trees in a c++ wrapper, it just might be what you want , we can make a
redland feed into that : 
http://prdownloads.sourceforge.net/introspector/itrspct-clunky-old.tgz


>Sorry if these are naive/obvious
> questions...
very good questions. We are testing the rdf using the perl interface
now, outside of the compiler. 
> 
> > > I started to look into this option (a couple years ago now), RMS
> sent
> > > me a
> > > 'cease and desist letter', which kinda took the wind out of my
> sails.
> > well i have had lots of interactions with RMS, he is just trying to
> > play politics. Most of the gcc guys dont like the idea of making
> > interfaces, but they will like it when we are done.
> >
> > > I know this has been a long-standing debate, but I never got any
> clear
> > > answers except for 'RMS don't like it, and I'm tired of arguing
> with
> > > him about it', and RMS replying 'I don't have time to go into
> details,
> > > I just don't like it'. Oh well. It finally appears that there's
> enough
> > > momentum for this to finally get somewhere. :-)
> 
> > yes, please do help. get yourself a Sourceforge account and mail it
> to
> > me.
> 
> cperras is my sourceforge account. I just read from Redland's site
> that
> sourceforge has a compiler farm. That's really cool. I'll have to
> check
> that out.

adding you now. welcome aboard!

> 
> > > I've looked into several related projects, including OpenC++,
> gccxml,
> > > and
> >
> > > PDT (http://www.cs.uoregon.edu/research/paracomp/pdtoolkit/), and
> > I might have seen this, but it is not free.
> 
> Yes, the license seemed to indicate it was, but the EDG front-end is
> not
> freely redistributable.

We have a project member that uses the EDG front end, djbarker,
maybe he can tell us some of his experince with EDG?

> > > Root
> > > (http://root.cern.ch/).
> > that is new
> 
> It's pretty interesting. Like most of these projects, however,
> there's a
> number of restrictions placed on the C++ code.
> 
> > >  I'd be happy to try to help out on this project. Some things I
> have
> > > potentially relevant knowledge of include:
> > >
> > > c, c++, gccxml, openc++ (tho it's been a little while), pdt, xml,
> > > mysql/odbc, boost. I'm not very skilled with Perl or Bison/Yacc.
> My
> > > main linux dev box has been having hardware problems, and also
> for a
> > > few other reasons, win32 is my main dev platform right now.
> >
> > ok, then you might want to help with the testing of the debian
> packaging
> > of the gui elements for mingw32/cygwin. Mike Garnsey and I have
> been
> > working on porting gtk to windows via the deb packaging system for
> the
> > gui.
> 
> I really want to focus on C++ reflection right now, and get that
> working
> on win32 if it's not already. 
that is not working yet.

>I'm not sure how the gui will help with
> that.

for visualization, for uml diagramming

> OTOH, I've been looking into porting gtk/gtkmm to win32 off and
> on.

ok, i am just finishing up the win32 port of gtk, we have %90 done

> If I have extra time, I can help with this effort. What kind of
> testing do
> you need?
> 
> > > One thing I noticed is that, for some reason, gcc doesn't keep
> track
> > > of the column number while it's parsing (well, the tree node
> doesn't
> > > keep track anyway). I've considered amending this; I don't know
> if
> > > this would be useful to introspector tho.
> >
> > you can turn that on in bison
> 
> Does it require modification of the parse tree to actually store the
> column? Otherhwise, unless there's a parse error, I think it's just
> ignored.

There is a bison flag for that, lemme google
http://www.informatik.uni-hamburg.de/RZ/software/gnu/gcc/bison_7.html#SEC73

Best regards,
mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Introspector-developers] current status

[<cr...@is...>]

On Sat, 21 Dec 2002, James Michael DuPont wrote:

> hey craig,
> thanks for writing. Come and visit us on the #introspector
> irc.openprojects.net for a chat.

Email is my preferred communication medium, but I'll consider getting an
IRC client (folks on the schmoo and a couple other lists wanted to chat
via IRC as well; I guess I'm just not the chatty type :-/).

Note that I'm going to be celebrating Yule/Winter Solstice for most of
this weekend.  After that I should have some time over the holidays.

> > Hey -
> >
> > I've been looking at this and gccxml. It's a little hard for me to
> > figure out what the current status of this project is. Will this work
> > on win32?

> yes it will, with cygwin, i have been testing with the 3.2, but the
> berkley db support of redland is not dont on win32.

I don't know much about redland or RDF (tho I know a bit about XML
Schema). Can we use mysql rather than berkely db, or is redland itself not
ported to win32? I did not see cygwin listed on redland's site.

Do you currently serialize the parse tree in binary format, or do you only
write it out to xml/rdf? Does it make sense to use binary format? Was part
of the vision to allow arbitrary modification of the parse tree during
compilation, and if so, would that require converting the xml/rdf back to
binary format for gcc to process? Sorry if these are naive/obvious
questions...

> > I started to look into this option (a couple years ago now), RMS sent
> > me a
> > 'cease and desist letter', which kinda took the wind out of my sails.
> well i have had lots of interactions with RMS, he is just trying to
> play politics. Most of the gcc guys dont like the idea of making
> interfaces, but they will like it when we are done.
>
> > I know this has been a long-standing debate, but I never got any clear
> > answers except for 'RMS don't like it, and I'm tired of arguing with
> > him about it', and RMS replying 'I don't have time to go into details,
> > I just don't like it'. Oh well. It finally appears that there's enough
> > momentum for this to finally get somewhere. :-)

> yes, please do help. get yourself a Sourceforge account and mail it to
> me.

cperras is my sourceforge account. I just read from Redland's site that
sourceforge has a compiler farm. That's really cool. I'll have to check
that out.

> > I've looked into several related projects, including OpenC++, gccxml,
> > and
>
> > PDT (http://www.cs.uoregon.edu/research/paracomp/pdtoolkit/), and
> I might have seen this, but it is not free.

Yes, the license seemed to indicate it was, but the EDG front-end is not
freely redistributable.

> > Root
> > (http://root.cern.ch/).
> that is new

It's pretty interesting. Like most of these projects, however, there's a
number of restrictions placed on the C++ code.

> >  I'd be happy to try to help out on this project. Some things I have
> > potentially relevant knowledge of include:
> >
> > c, c++, gccxml, openc++ (tho it's been a little while), pdt, xml,
> > mysql/odbc, boost. I'm not very skilled with Perl or Bison/Yacc. My
> > main linux dev box has been having hardware problems, and also for a
> > few other reasons, win32 is my main dev platform right now.
>
> ok, then you might want to help with the testing of the debian packaging
> of the gui elements for mingw32/cygwin. Mike Garnsey and I have been
> working on porting gtk to windows via the deb packaging system for the
> gui.

I really want to focus on C++ reflection right now, and get that working
on win32 if it's not already. I'm not sure how the gui will help with
that. OTOH, I've been looking into porting gtk/gtkmm to win32 off and on.
If I have extra time, I can help with this effort. What kind of testing do
you need?

> > One thing I noticed is that, for some reason, gcc doesn't keep track
> > of the column number while it's parsing (well, the tree node doesn't
> > keep track anyway). I've considered amending this; I don't know if
> > this would be useful to introspector tho.
>
> you can turn that on in bison

Does it require modification of the parse tree to actually store the
column? Otherhwise, unless there's a parse error, I think it's just
ignored.

--craig