introspector-developers — for anyone interested in hacking the introspector

[Introspector-developers] introspector-mingw32@lists.sourceforge.net and zlib beta

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

This is a message to all the introspector developers,
we have a new mailling list for discussion of the mingw32 port 
of the introspector, currently we are at the GTK, working on zlib,
libpng, and gdk and others.


Here is a Beta build of zlib,
as usual http://introspector.sourceforge.net/debian/incoming/
Here is the dupload log files :
u zlib-mingw32-1g_1.1.4-5_i386.deb introspector.sf.net Thu Oct 24
02:43:11 2002
u zlib-mingw32_1.1.4-5.dsc introspector.sf.net Thu Oct 24 02:43:11 2002
u zlib-mingw32-1_1.1.4-5_i386.deb introspector.sf.net Thu Oct 24
02:43:11 2002
u zlib-mingw32-1-altdev_1.1.4-5_i386.deb introspector.sf.net Thu Oct 24
02:43:11 2002
u zlib-mingw32-1g-dev_1.1.4-5_i386.deb introspector.sf.net Thu Oct 24
02:43:11 2002
u zlib-mingw32-bin_1.1.4-5_i386.deb introspector.sf.net Thu Oct 24
02:43:11 2002
u zlib-mingw32_1.1.4-5.tar.gz introspector.sf.net Thu Oct 24 02:43:11
2002
u zlib-mingw32_1.1.4-5_i386.changes introspector.sf.net Thu Oct 24
02:43:11 2002
s zlib-mingw32_1.1.4-5_i386.changes introspector.sf.net Thu Oct 24
02:43:11 2002


--- James Michael DuPont <mdu...@ya...> wrote:
> Mike 
> I have setup a new list for the win32 port discussion,
> mike
> .....................................................
> The web page for users of your mailing list is: 
> 
>     https://lists.sourceforge.net/lists/listinfo/introspector-mingw32
> 
> You can even customize these web pages from the list configuration
> page.  However, you do need to know HTML to be able to do this.
> 
> There is also an email-based interface for users (not administrators)
> of your list; you can get info about using it by sending a message
> with just the word `help' as subject or in the body, to:
> 
>     int...@li...
> 
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
> 


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

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

[Introspector-developers] home page for Dia win32 debian build effort

[Mike G. <mik...@ya...>]

FYI - I have set up a home page
(http://introspector.sourceforge.net/dia_win32.htm)
for the in-progress effort to create a set of Debian
packages to enable a COMPLETE build of Dia for Win32
target on a Debian Linux development platform using
MinGW cross-build tools. This effort is part of the
"Introspector" project.

FWIW, this web page includes a list of Dia
dependencies that I hope may be of use to all Dia
developers.

Work on the various assorted Dia dependencies is
progressing quite well (glib2 & libxml2 have been
cross-built; gtk+ is in progress).  As usual,
volunteers are welcome!!!  

Cheers!  Mike Garnsey

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

[Introspector-developers] Fwd: Re: TreeCC for the GCC (was [DotGNU]IRC Meeting Summary : 2002-10-19)

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

Dear Introspector developers,

I have been busy on a couple of fronts this weekend,

The support for the treecc is the first step in the support for the
pnet/dotgnu c#. In this attached mail at the end of this,  you will
find the first step in the support of c# as a programming interface
into the gcc. This might be interesting to all introspector developers,
because it creates an user level API into the gcc tree nodes with an
explicit interface and an OO syntax.

The GCC/ perl interface, I have gotten my older GCC/CSCC (C#)/Perl
module out of the backup system, That is a 16mb dll that contains the
gcc and the cscc as a perl module. This I will be rebuilding for the
newest version of c# and gcc.

The MINGw32 porting, currently I am still working on the porting of
zlib and libpng to the minw32 under the debian cross compiler, that did
not get too much time. I think the full GTK port will be taking anther
couple of weeks unless someone else wants to help work on it?

mike

--- James Michael DuPont <mdu...@ya...> wrote:
> From James Michael DuPont Sun Oct 20 03:42:52 2002
> Received: from [80.128.227.104] by web13310.mail.yahoo.com via HTTP;
> Sun, 20 Oct 2002 03:42:52 PDT
> Date: Sun, 20 Oct 2002 03:42:52 -0700 (PDT)
> From: James Michael DuPont <mdu...@ya...>
> Subject: Re: TreeCC for the GCC (was [DotGNU]IRC Meeting Summary :
> 2002-10-19)
> To: DotGNU Mailing List <dev...@do...>
> In-Reply-To: <200...@md...>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Length: 1356
> 
> 
> --- Gopal V <gop...@sy...> wrote:
> > 
> > IRC Meeting -- 2002-10-19
> > -------------------------
> 
> One of the things that came out of the meeting that was important for
> me is a starting point on the gcc/treecc interface.
> 
> I have started on the TreeCCGenerator.pm as part of the introspector,
> based on the JavaGenerator.pm I have had the following problems.
> 
> 1. dependancies, I do not yet have a full topological sort of the
> nodetypes dependancies worked out, that means that I cannot put the
> files (yet) into the right order for including and compilation.
> 
> But the treecc seems to output the resulting .cs files
> with the object in the right order...
> 
> This is a problem , because there does not seem to be an include
> blocker system to ifdef X, define X, elseif the blocks of code.
> The tree still produces the output and there are not any cycles, so
> it
> does not matter.
> 
> So, the next step is to sort the nodes and output just one DAG graph
> of
> all the include, I need to secondguess the includes from treecc.
> 
> 
> 2. interfaces, multiple inheritance.
> I use interfaces to mix in attributes and methods into the nodes,
> 
> for example 
> 
> %node node_integer_cst  node_const 
> the node_integer_cst is a node_const, but 
> this supports the interface : node_Ityped
> 
> I have just added in the field 	 
> node_base type; 
> into the node to point to the type. And unfortunally, it points to a
> node_base and not the node_type. That will be fixed later.
> 
> But the methods are turned off for now.
> 
> Summary: 
> 
> You can find a snapshot of the current files on
> http://introspector.sourceforge.net/dotgnu/introspect_treecc.tgz
> 
> I think the way to go with this is to get the treecc stuff generated,
> the I hope there is someway to use the c interfaces to talk to the c#
> interfaces. Right now I guess the c and c# interfaces are excluding
> each other, it would be great if I could fill out the c interface and
> automagically feed that to the c# interface.
> 
> Of course, this needs to be compiled, and documented and all that.
> 
> My current plan is to modify the tree dumper to not output the XML
> from
> the gcc, but to fill out the new treecc generated structures, that
> plus
> the treecc binding will provide an interesting callback system for
> testing high speed access to the gcc nodes.
> 
> Also, the inclusion of a native pointer to the original tree
> structure
> will allow random access traversal, not just callbacks.
> 
> I hope you find this interested, it is only work in progress, but
> would
> be greatful for any feedback and ideas you have.
> 
> mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
> 


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

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

Re: [Introspector-developers] Introspector GCC Schema Draft

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

Dear Introspector developers.I have following source code available.on the serverhttp://introspector.sourceforge.net/cygwin/The sources are bzipped.You need tar "-xjf filename" to  expand them.These are mostly compatible with the cygwin gcc 3.2 release,I needed the build of the normal cygwin libjava to test the javacomponents. Just install the cygwin gcc, and copy these exes over the backed up old ones in the lib subdirectory.These are the binarys for cygwin patched, you can install this over your installed gcc to get thelibjava install of the normal cygwin. The java compiler is put into a form of permiscuous mode.These are the sources, patched and cleaned.[   ] cvs_patched_clean.tbz   18-Oct-2002 10:54  20.4M  Just the FACTS, Mame.Here are the tools you need to test out the new system.new cc1.exe[   ] patched_compilers.tbz   18-Oct-2002 11:17  13.2M  This is a snapshot of the configured and built sourcewith all object files. WASTE OF SPACE[   ] cvs_patched_fat.tbz     18-Oct-2002 11:06  50.4M  Here are the pristine sources.[   ] cvs_sources.tbz         18-Oct-2002 11:10  18.6M  Here are the executables and the includes.I did a install --prefix and then tar b zipped them.[   ] patched-binary.tbz      18-Oct-2002 11:14  16.8M  I hope you like them, I am working on the linux version.MikeMike

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


---------------------------------
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos, & more
faith.yahoo.com

[Introspector-developers] Re: Test JAVA XML dumping from GCC introspector

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

Here are some results of the XML dumping of Java code.
I have only uploaded 
http://introspector.sourceforge.net/javaxml.zip

In this zip you will find the following files :
test.java           -- The hello world java program
test.java.class     -- The dump of the class information
test.java.original  -- The dump of the memory 
test.java.original2 -- The dump of the memory again, I think there is
somthing going on here... I dont know the real difference yet.

class.xsd          -- An updated Xml Schema 
Thanks to xmlspy for some help. :)

This was produced on a cygwin build of java with the introspector patch
applied. There are some issues with tree_vec objects, they had to be
manually edited, and the "<>" need to be translated over to &lt;, I
have some code for that at home.

The importance of this is that we can dump C, C++, objective C and Java
code with these patches. This is the patched ast-optimizer branch.

I hope you find it interesting. 

I am building the new version at home on linux, and will be posting all
that to the server this weekend.

If anyone is interested in testing this, I would appreciate.
mike


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

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

[Introspector-developers] Introspector GCC Schema Draft

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

Dear All,
here is the beginning of an XML shema for the introspector GCC
interface.
mike
.........................................................
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">

	<xs:element name="xmlroot">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="node" type="nodeType" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>

	<xs:complexType name="nodeType" mixed="true">
		
		<xs:choice minOccurs="0" maxOccurs="unbounded">

			<xs:element name="args" type="argsType"/>
			<xs:element name="argt" type="argtType"/>
			<xs:element name="base" type="baseType"/>
			<xs:element name="binf" type="binfType"/>
			<xs:element name="bpos" type="bposType"/>
			<xs:element name="chan" type="chanType"/>
			<xs:element name="clas" type="clasType"/>
			<xs:element name="domn" type="domnType"/>
			<xs:element name="element" type="elementType"/>
			<xs:element name="elts" type="eltsType"/>
			<xs:element name="flds" type="fldsType"/>
			<xs:element name="fncs" type="fncsType"/>
			<xs:element name="init" type="initType"/>
			<xs:element name="max" type="maxType"/>
			<xs:element name="min" type="minType"/>
			<xs:element name="mngl" type="mnglType"/>
			<xs:element name="name" type="nameType"/>
			<xs:element name="prms" type="prmsType"/>
			<xs:element name="ptd" type="ptdType"/>
			<xs:element name="purp" type="purpType"/>
			<xs:element name="retn" type="retnType"/>
			<xs:element name="scpe" type="scpeType"/>
			<xs:element name="size" type="sizeType"/>
			<xs:element name="srcp" type="srcpType"/>
			<xs:element name="type" type="typeType"/>
			<xs:element name="valu" type="valuType"/>

			<xs:element ref="algn"/>
			<xs:element ref="binlen"/>
			<xs:element ref="high"/>
			<xs:element ref="lngt"/>
			<xs:element ref="low"/>
			<xs:element ref="prec"/>
			<xs:element ref="srcl"/>
			<xs:element ref="str"/>
			<xs:element ref="strg"/>
			<xs:element ref="used"/>
		</xs:choice>
		
		<xs:attribute name="idx" type="xs:short" use="required"/>
		<xs:attribute name="node_name" type="xs:string" use="required"/>
	
	
	</xs:complexType>
	
	<xs:complexType name="initType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="argsType">		
		<xs:annotation >This should be a collection
		</xs:annotation>
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="elementType">
	<xs:annotation>This is the element of vector </xs:annotation>
		<xs:attribute name="item" type="xs:byte" use="required"/>
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	

	<xs:element name="algn" type="xs:byte"/>
	<xs:element name="binlen" type="xs:byte"/>
	<xs:element name="built-in">
		<xs:complexType/>
	</xs:element>
	<xs:element name="lngt" type="xs:byte"/>
	<xs:element name="low" type="xs:int"/>
	<xs:element name="srcl" type="xs:int"/>

	<xs:element name="str">
	<xs:annotation>
	This is the description of the class
	</xs:annotation>
		<xs:simpleType>
			<xs:restriction base="xs:string">
				<xs:enumeration value="artificial"/>
				<xs:enumeration value="extern"/>
				<xs:enumeration value="static"/>
				<xs:enumeration value="struct"/>
				<xs:enumeration value="undefined"/>
				<xs:enumeration value="union"/>
				<xs:enumeration value="unsigned"/>
			</xs:restriction>
		</xs:simpleType>
	</xs:element>


	<xs:element name="strg" type="xs:string"/>

	<xs:element name="prec">
	<xs:annotation>
	This is the bytelength of the object
	</xs:annotation>

		<xs:simpleType>
			<xs:restriction base="xs:byte">
				<xs:enumeration value="16"/>
				<xs:enumeration value="32"/>
				<xs:enumeration value="36"/>
				<xs:enumeration value="64"/>
				<xs:enumeration value="8"/>
			</xs:restriction>
		</xs:simpleType>
	</xs:element>
	
	
	<xs:complexType name="argtType">
	<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="baseType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="binfType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="bposType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="chanType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="clasType">
		<xs:attribute name="idx" type="xs:short" use="required"/>			
	</xs:complexType>

	<xs:complexType name="domnType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="eltsType">
		<xs:attribute name="idx" use="required" type="xs:short">
		</xs:attribute>
	</xs:complexType>

	<xs:complexType name="fldsType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>

	<xs:complexType name="fncsType">
		<xs:attribute name="idx" type="xs:short" use="required"/>			
	</xs:complexType>

	<xs:element name="high" type="xs:int"/>

	<xs:complexType name="maxType">
				<xs:attribute name="idx" type="xs:short" use="required"/>			
					</xs:complexType>
					
	<xs:complexType name="minType">
		<xs:attribute name="idx" type="xs:short" use="required"/>			
	</xs:complexType>
	
	<xs:complexType name="mnglType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	
	<xs:complexType name="nameType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	


	<xs:complexType name="prmsType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	<xs:complexType name="ptdType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	<xs:complexType name="purpType">
		<xs:attribute name="idx" use="required">
			<xs:simpleType>
				<xs:restriction base="xs:NMTOKEN">
					<xs:enumeration value="14"/>
					<xs:enumeration value="38"/>
				</xs:restriction>
			</xs:simpleType>
		</xs:attribute>
	</xs:complexType>
	<xs:complexType name="retnType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	<xs:complexType name="scpeType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	<xs:complexType name="sizeType">
		<xs:attribute name="idx" type="xs:short" use="required"/>			
	</xs:complexType>
	<xs:complexType name="srcpType" mixed="true">
		<xs:choice minOccurs="0" maxOccurs="unbounded">
			<xs:element ref="built-in"/>
		</xs:choice>
	</xs:complexType>
	<xs:complexType name="typeType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
	<xs:element name="used">
		<xs:simpleType>
			<xs:restriction base="xs:boolean">
				<xs:enumeration value="0"/>
				<xs:enumeration value="1"/>
			</xs:restriction>
		</xs:simpleType>
	</xs:element>
	<xs:complexType name="valuType">
		<xs:attribute name="idx" type="xs:short" use="required"/>
	</xs:complexType>
</xs:schema>


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

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

[Introspector-developers] Status report

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

Hi all, 
Have been busy on a couple of fronts lately.

We currently have the following things running :

1. Setting up a port of to windows via the debian cross compiler
Mike Garnsey has been doing a great job on that, and is working on a
detailed status report.
He has also updated the sf task list and been doing lots of testing and
documentation. Thanks mike.

2. Restarting the VCG development, and porting to GTK (and to windows
via the Mingw32 port ). I have requested a GNUVCG project on
gnu.savannah.org, and we are awaiting the name approval from the fsf.
There have been some people interested in that who have joined the
list,
Malcolm Parsons has supplied some patches to that.

3. Setting up the GCC XML dumping of the Abstract syntax trees, this
will allow people to extract information from existing programs. We
will be checking the gcc AST-optimizer-branch into this cvs in the next
days. 
Mario Luca Bernardi has signed up for testing/maintaining that part,
when he is finished with his exams.

4. Creating an interface into Inline perl. I have some experimental
code to create inline code that gets sent to the patched gcc.

5. The cscc c# interface, I have been in contact with the pnet cscc
compiler writers. The Cscc will be provide all types of interesting
infomation about c# programs. I hope to provide an C# interface to the
gcc as well, because it allows a much more structured api than perl.

6. Bison, there is also an Bison XML patch that I want to share with
you.

7. The LIBXML/RDFLib interface to the metadata.
this component is in planning stage right now.

8. Creating a proper web page,
The current web pages are a mess, i know.
Many people have expressed interested in helping.

9. Source forge package management 
The http://sourceforge.net/projects/wide/ provides an upload capability
to sourceforge. I am trying to get that running so we can get the
packages automaticallly uploaded.

So as you can see there is alot going on in the background.
Also I have noticed that many new people have joined the list, if
anyone is interested in testing these tools or in helping out with any
on them, please make yourself known.

If anyone wants to take over the task managment for one of this
subprojects, please make yourself known.

mike

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

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

[Introspector-developers] Fwd: XML dumping and GraphViz/VCG in the GCC ast-optimizer-branch

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

Dear Hackers,
The time has come to moblize and to get this project kicking.
I see no reason to be afraid of "Killing the GPL" any more, 
the gcc developers are working on similar modules, and we will be 
just left out if we dont get in on that action.

What do you think?

mike

--- James Michael DuPont <mdu...@ya...> wrote:
> From James Michael DuPont Tue Oct 15 07:00:36 2002
> Date: Tue, 15 Oct 2002 07:00:36 -0700 (PDT)
> From: James Michael DuPont <mdu...@ya...>
> Subject: XML dumping and GraphViz/VCG in the GCC ast-optimizer-branch
> To: gc...@gn...
> 
> Dear GCC developers,
> 
> I was really suprized and happy to see the patches applied to the 
> ast-optimizer-branch from Sebastian Pop. 
> His XML dumping of call graphs is very useful. 
> Can I take this as general acceptance of XML dumping in the gcc? 
> 
> At least it has not been attacked or criticized on the mailling list.
> 
> Also the dump-tree-dot module dumps into a format for the non-free
> software dot, a part of graphviz. I take this is an accepted practice
> of dumping tree structures for explict usage by non-free software? 
> 
> I hope that this is an indication that there is no longer any policy
> problem of using the ast-dumps from the gcc by other free software
> modules? I mean if the output is meant for non-free software, then
> you
> must be happy to have this output used by free software.
> 
> Or is the contents of the CVS not an indication of policy at all, 
> with the policy makers not enforcing them, and the cvs commiters not
> asking for permission?
> 
> There have been many people who are interested in using the
> introspector for creating free software. I have been trying to
> convince
> people that it is better to not output asts to non-free software or
> xml. But if the gcc is accepting patches to do the same, then I would
> be silly not to follow suite. 
> 
> In fact, I cannot see any real reason anymore to get stressed out
> about
> this issue at all. 
> 
> We am going to be re-starting up the binary distribution of the
> patched
> gcc for full dumping of function bodies into xml and post processing
> in
> perl. I had taken them down out of respect to some or Also we we will
> be creating a local branch of the gcc ast-optimizer branch in the
> introspector.sf.net repository.
> 
> My goal is to create a statically linked visualization and
> manipulation
> tool under the GPL by gluing togeather the components of the VCG,
> GNOME
> DIA, GCC and Perl. 
> 
> The VCG is a GPLed software that provides similar functions to 
> GraphVis, In fact I have now gotten an "Un-Uglified" copy of the
> sources from the author, and will be pushing to get the Gcc users to
> switch over to use free software.
> 
> Also I have planned out an exchange of the ast information via
> in-memory trees stored in the libxml2 dom structures. That would
> allow
> for the visualization tools to get a "Live feed" from the compiler as
> a
> push data feed. I hope that it will eliminate the need for external
> representation, in fact the entire system could be statically linked
> into one huge monolithic application. That would also include an
> embedded perl for a script interpreter.
> 
> Anyway, we have many discussions about this issue on the list in the
> past, and I think this whole issue of external representation is
> really
> turning out to be a free-for-all where is it easier to ask for
> forgiveness then for permisison, not following any real guidelines.
> It
> is now time for me to get back in on this free-for-all, otherwise I
> will just be left out.
> 
> Mike
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> 


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

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

Re: [Introspector-developers] Status report / Call for ideas

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

--- Mike Garnsey <mik...@ya...> wrote:
> --- James Michael DuPont <mdu...@ya...> wrote:
> <snip>
> > 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.
> 
> Mike, thanks for the update on Introspector.  The plan
> that you lay out looks sound ...but not for the faint
> of heart ;) 

Yes, It is bold. 
But we should be able to create it module by module. One thing that I
wanted to get way some feedback as to priority. I know that most people
are interested in the gcc interface, but for me the DIA work is the
most  important at this time.

> Anyways, I'll take a 1st cut at feedback
> and ideas....
Thanks.

> 
> > Here is my proposal for components of the 
> > introspector :
> > Data extraction, manipulation, visualization, and
> > generation.
> 
> excellent!  I'm thinking that a 5th component might be
> in order:  a "knowledge acquisition" component.  Idea
> being for the Introspector user to gain knowledge or
> insight about a particular facet.  I see visualization
> tools doing some of this, but I see the need to be
> able to easily be able to gain insight to things like:
> 
>      'what does this method do?'
>      'what is the purpose of this lib?'
>      'what does this compiler switch setting do?'

Yes, I think this will come under two areas:
   1. annotation - People add in this information.
   2. association - we look for this information in mailling lists for
example based on keys from the program.

Of course this is all predicated on the idea that we can reference a
single node of infomation. More about that later.

> wrt scripting notion, how about an external control
> mechanism for Instrospector (maybe xmlRPC) too?

Yes, at first we will support a glib/gtk like c/perl interface.
Then a bonobo/orbit/corba object interface.
and then a webservices/xmlrpc/soap external interface.

The basis for this is an object model that I have been prototyping in
perl. We read in the tree structure from the gcc and annotate it with
inheritance, remove fields factor them into base classes, define
properties and callbacks. Then from this model, we will generate the
various interfaces via meta-programming. 

I have prototyped various perl, java and other output languages.

> 
> I think that working up some use-cases for
> Introspector would be helpful at this point.
Yes, I have a small set of them worked out. The trick is to define
a model/viewer/controller hierachy.

model being the tree structures, the object meta data. The controller
being imports but also DIA/Emacs/GUIS updating. The viewer being the
layout engines and extractors, even code generators.

but yet, a use case catalog would be great. I have started that.
The one use case is Expansion :

by expansion, the user selects pick a node and expands apon it in a
certain direction,  adding in more fields, finding related nodes,
bringing in more context. 
For the exploritory part of the usage of the introspector, a user will
be doing a continuing series of expansions. 

The selection mechanisms will be database queries, clicking on things,
traversals through the structure.

>  Bredth
> and depth!  Some system level ones (bredth) would be
> great for helping to convey the 'big picture' of what
> Introspector is all about.  


> Component level (depth)
> use cases would be good to provide some specific
> glimpes of Introspector in action wrt graphs (VCG),
> diagrams (Dia), etc.  The later could be very usefull
> in communicating with and/or enlisting support from
> other opensource teams, or to get feedback on existing
> tools/techniques for certain aspects of Introspector
> functionality.

Yes, we should create a distribution of all the tools named, and
prepare even simple perl scripts to glue them togeather to begin with.
The dia tool can be used immediatly for diagrams. In fact, I have a few
that I can publish...

I aggree with you, we need to start providing more visable results of
this program. I have tons and tons of notes and diagrams, links and
bits and bobs. This will need to be translated into something digital.

mike

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

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

Re: [Introspector-developers] Status report / Call for ideas

[Mike G. <mik...@ya...>]

--- James Michael DuPont <mdu...@ya...> wrote:
<snip>
> 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.

Mike, thanks for the update on Introspector.  The plan
that you lay out looks sound ...but not for the faint
of heart ;)  Anyways, I'll take a 1st cut at feedback
and ideas....

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

excellent!  I'm thinking that a 5th component might be
in order:  a "knowledge acquisition" component.  Idea
being for the Introspector user to gain knowledge or
insight about a particular facet.  I see visualization
tools doing some of this, but I see the need to be
able to easily be able to gain insight to things like:

     'what does this method do?'
     'what is the purpose of this lib?'
     'what does this compiler switch setting do?'
> 
> 1. The ability to extract meta-data from existing
> programs
> this meta data is 
> a. what structures are defined in your program

good.

> b. what functions are declared and defined

you betcha!

> c. which functions use what functions, etc.

AMEN!!!

ok, the rest of the presented material looks good at
first blush....especially the libXML approach.  

Here's a couple of random thoughts:

wrt scripting notion, how about an external control
mechanism for Instrospector (maybe xmlRPC) too?

I think that working up some use-cases for
Introspector would be helpful at this point.  Bredth
and depth!  Some system level ones (bredth) would be
great for helping to convey the 'big picture' of what
Introspector is all about.  Component level (depth)
use cases would be good to provide some specific
glimpes of Introspector in action wrt graphs (VCG),
diagrams (Dia), etc.  The later could be very usefull
in communicating with and/or enlisting support from
other opensource teams, or to get feedback on existing
tools/techniques for certain aspects of Introspector
functionality.

well, thats all I have time for now...more to follow. 


Keep up the good work!

Mike G.

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

[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

[Introspector-developers] Re: Status Report for debian packaging of libiconv for windows32

[Bruno H. <br...@cl...>]

James Michael DuPont writes:

> http://www.cygwin.com/ml/cygwin-xfree/2002-04/msg00566.html
> (btw: They say that the autoconfiguration of libiconv is EVIL)

This has been fixed in libiconv-1.8.

> Here is the configure that I am using : 
> ./configure --cache-file="cross-config.cache"  --target=mingw32msvc
> --host=i586-mingw32msvc --build=i586-pc-linux-gnu

The --target option is useless here, because libiconv is not a
compiler. You should give --host=i586-mingw32 instead.

Bruno

[Introspector-developers] Status Report for debian packaging of libiconv for windows32

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

Dear Fellow Hackers,

I have been busy getting the Debian packaging of the needed packages
for DIA under win32 for the Min32 cross compiler going, and would
appreciate some help at this point. 

For those of you who dont know what I am trying to do : I want to
create a set of packages for compiling the DIA program for windows from
scratch under debian so that we can create binaries for DIA without
having to buy the expensive microsoft software (or install illegal
copies of it (Yuk!))

I am using mingw the compiler for debian from ron (thanks!).

First of all, the debian packaging is coming along, there are some
questions about where to install and what architecture to use. 
Currently, debian thinks it is a i386-linux but the compiler is
building for windows. I will have to research how this all works.

Anyway, here are my silly questions / statements of problems and
solutoins followed by a set of instructions on how to reproduce the
packages yourself (under debian). If you have a bit of time, please try
and reproduce these packages and tell me if they worked, and what you
think of the idea.

######################################################
First

I tried to set the architecture, but it is not working.

It would be nice to find some way to say that the target architecture
is  mingw32. Even better would be to be compatible with the Debian
packaging tool that is running under cygwin!!

export DEB_HOST_ARCH=i586
export DEB_HOST_GNU_CPU=i586
export DEB_HOST_GNU_TYPE=i586-mingw32msvc
export DEB_HOST_GNU_SYSTEM=mingw32msvc

In the debian/control file I have set : 
Architecture: i386 (Tried i586 and i586-mingw32msvc)
Depends: mingw32, libtool	

Now, the dpkg-gencontrol complains that anything else is not know to
it, 
so I hope that someone can advise on this.

######################################################
Secondly :

The packages install for now under :
/usr/local/introspector/win32 for lack of any creativity.
They are windows binaries, but just go into the debian tree.
I am sure this is suboptimal.
Any ideas? Maybe I will have to read the debian policy again.... 

######################################################
Thirdly, I dont have the DLLS going yet. Just what seems to be static
libs .a/.la and all the rest. For me that is not such an issue, I just
want to link, dont care about DLLs or not. The important thing is that
you can build the libs from the debian package without much stress.
So that will be a lower priority, but important step.

######################################################
Fourthly :

Alot of my problems were coming from libtool which I have upgraded to 
libtool_1.4.2-7. The aclocal.m4 macros from libtool dont handle the
needed architecture string it looks for  *-*-mingw* and mingw*. 

In fact, the buildstring that I am using is: i586-mingw32msvc
So when I change them all to  *-mingw* alot of my problems go away.
I have merged the aclocal with Brunos original and followed the
instructions
http://www.cygwin.com/ml/cygwin-xfree/2002-04/msg00566.html
(btw: They say that the autoconfiguration of libiconv is EVIL)

######################################################
Fifthly : 
Another issue are the commands that I added to the configure.in
    AC_LIBTOOL_WIN32_DLL / AC_LIBTOOL_DLOPEN

When configure runs, it does not set them properly, I think this is
important for the DLL building
   enable_dlopen=yes / enable_win32_dll=yes

I am following the instructions According to :
http://sources.redhat.com/autobook/autobook/autobook_254.html

Here is the configure that I am using : 
./configure --cache-file="cross-config.cache"  --target=mingw32msvc
--host=i586-mingw32msvc --build=i586-pc-linux-gnu
--prefix=/usr/local/introspector/win32/libiconv --enable-dlopen=yes
--enable-win32_dll=yes

But I have to admit, I dont have a good understanding of this one
option, maybe you have some ideas?

Oh, I had to hack the ltmain.sh and got rid of some of these funky
commands (I don't think they are need?) : 
        # Install the pseudo-library for information purposes.
	#name=`$echo "X$file" | $Xsed -e 's%^.*/%%'`
	#instname="$dir/$name"i
	#$show "$install_prog $instname $destdir/$name"
	#$run eval "$install_prog $instname $destdir/$name" || exit $?

######################################################
Sixthly : 

I have setup a small debian upload on my introspector site,
there I will be posting all the packages to begin with.
Here is my ~/.dupload.conf script
------------------
package config; 
 $default_host = "introspector.sf.net";
 $cfg{'introspector.sf.net'} = { 
	fqdn => "introspector.sf.net", 	method => "scpb",
	incoming => "/home/users/m/md/mdupont/www/debian/incoming/",
	login    => "mdupont", 	dinstall_runs => 1,};  
1;
------------------
You can find the packages here
http://introspector.sourceforge.net/debian/incoming/
I will be putting all the packages need to compile and link the modules
there for now. 
 
######################################################

And Finally :

I would like to know if I did any of this right, it is all very new and
experimental right now. Here are the instructions for downloading and
testing the package. Please dont use this for anything important right
now.
------------------------------------------------------------------------
0. Install the libtool_1.4.2-7

Either from APT, or the debs I put here :
http://introspector.sourceforge.net/debian/incoming/libtool_1.4.2-7_i386.deb
http://introspector.sourceforge.net/debian/incoming/libltdl3_1.4.2-7_i386.deb
http://introspector.sourceforge.net/debian/incoming/libltdl3-dev_1.4.2-7_i386.deb
http://introspector.sourceforge.net/debian/incoming/libtool-doc_1.4.2-7_all.deb


1. Get the packages : 
wget
http://introspector.sourceforge.net/debian/incoming/libiconv1-dev_1.7-1_i386.deb
wget
http://introspector.sourceforge.net/debian/incoming/libiconv_1.7-1.dsc
wget
http://introspector.sourceforge.net/debian/incoming/libiconv_1.7-1.tar.gz
wget
http://introspector.sourceforge.net/debian/incoming/libiconv_1.7-1_i386.changes

2. unpack the sources
dpkg-source -x libiconv_1.7-1.dsc 

3. rebuild the package
dpkg-buildpackage -rfakeroot -sa -us -uc

4. install the package
sudo dpkg -i ../libiconv1-dev_1.7-1_i386.deb 

5. Test the package 
wine  -- /usr/local/introspector/win32/bin/iconv --help

Hope to hear from you,
Happy Hacking,
Mike

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

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: [Introspector-developers] Re: WIN32 compilation, the spirit of GNU software.

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

Obviously I will have to talk about the GPL again to 
answer this mail.

Please feel free to call me antisocial, troll-like, pedantic and also
raving mad, as well as criticize my bad spelling in this mail. It does
not change the facts at hand at all.

You will find my interpretation of the GPL, the GNU manifesto, the GPL
faq and the GNU webpage following in the mail.

Please ignore it if you dont care about my personal opinion on this
matter. It is not meant as an accusation or allegation to anyone.

The gnu manifesto describes the dependancy on one vendor or person can
only be alleviated by having FULL source code.

Remember that the situation the DIA is in, where one person decides to 
boycott the distribution of binaries, is ONLY a problem if you do not
live up to the GPL. 

If you accept binaries in your project that dont have the FULL source
code distributed in the same place as the binaries, and not all the
build directory structure, then you make it hard to reproduce the
binary. This is why the GCC and other GNU projects have stringent
requirements for thier projects, to avoid the situation that you are
in.

If you had all the sources and the scripts to compile them that were
used to create the binaries that you are distributing, then we would
have NO PROBLEM AT ALL.

Think about that, think about where the problem is. 

I am just pointing out the problem and trying to get the sources as
described in the GPL. 

Read the links I sent you. 

You may not aggree with this, but also look how cygwin does the port :
Binary + original source code + Diff to build + environment is all in
one place. That is what is needed for the DIA port.

My comments follow :
--- Lars Clausen <lrc...@cs...> wrote:
> On Fri, 23 Aug 2002, James Michael DuPont wrote:
> >  --- Cyrille Chepelov <cy...@ch...> schrieb: > Le Thu, Aug
> 22,
> > 2002, à 10:08:58PM +0200, James Michael DuPont a
> >> écrit:
> >> 
> >> > Ok, so people do build windows from cvs? Anyone out there who
> has?
> >> 
> >> Yes. Someone whom you've disgusted from distributing binaries
> >> anymore.
> > I mean someone besides hans.
> > 
> > Has anyone here ever built it? How much time has been wasted from
> > people besides myself who want to help?
> > 
> > What about from scratch,without any dlls?
> > did even he ever built it from scratch? 
> 
> Why would you ever want to build it from scratch, without any dlls? 
> We can
> hardly be required to provide build scripts for the libraries that
> Dia
> requires.  I don't build GTK from scratch on Linux, why should I?  

To port it to mingw. To reproduce the work hans has done.
To understand the source code. This is the spirit of GNU.

see :http://www.gnu.org/gnu/manifesto.html
----------------------------------------------------------------
Complete system sources will be available to everyone. As a result, a
user who needs changes in the system will always be free to make them
himself, or hire any available programmer or company to make them for
him. Users will no longer be at the mercy of one programmer or company
which owns the sources and is in sole position to make changes. 
----------------------------------------------------------------
Here, complete is the word. We are not at the mercy of one person to
"run away with the ball". That means if one person decides not to
produce binaries anymore, we can produce them because we have the
COMPLETE SYSTEM SOURCE CODE, all the sources of all the components that
are not part of the OS. 

Again the GNU manifesto :
----------------------------------------------------------------
If your business needs to be able to rely on support, the only way is
to have all the necessary sources and tools. Then you can hire any
available person to fix your problem; you are not at the mercy of any
individual. With Unix, the price of sources puts this out of
consideration for most businesses. With GNU this will be easy. It is
still possible for there to be no available competent person, but this
problem cannot be blamed on distribution arrangements. GNU does not
eliminate all the world's problems, only some of them. 
----------------------------------------------------------------

Ok, again, we need *ALL* the sources. 

now see : http://www.gnu.org/gnu/thegnuproject.html
----------------------------------------------------------------
You have the freedom to modify the program to suit your needs. (To make
this freedom effective in practice, you must have access to the source
code, since making changes in a program without having the source code
is exceedingly difficult.) 
----------------------------------------------------------------


See section 3 of the GPL : 
----------------------------------------------------------------
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to control
compilation and installation of the executable. However, as a special
exception, the source code distributed need not include anything that
is normally distributed (in either source or binary form) with the
major components (compiler, kernel, and so on) of the operating system
on which the executable runs, unless that component itself accompanies
the executable. 
----------------------------------------------------------------

"is normally distributed (in either source or binary form) with the
major components (compiler, kernel, and so on) of the operating system"

libiconv, gettext, glib and gtk are distributed with debian and are
easy to compile.  Under windows it is a nightmare!
The port to windows needs all of that this is very clearly covered by
the GPL.

----------------------------------------------------------------
If distribution of executable or object code is made by offering access
to copy from a designated place, then offering equivalent access to
copy the source code from the same place counts as distribution of the
source code, even though third parties are not compelled to copy the
source along with the object code. 
----------------------------------------------------------------

NOTE : "from the *same* place counts as distribution of the source
code"
That means you have to put the sources in the same place as the
executables, my asking of hans for the sources of the binaries is
completly legitimate.

The faq says :
----------------------------------------------------------------
http://www.gnu.org/licenses/gpl-faq.html#AnonFTPAndSendSources
----------------------------------------------------------------
The sources you provide must correspond exactly to the binaries. In
particular, you must make sure they are for the same version of the
program--not an older version and not a newer version. 
----------------------------------------------------------------


The GPL faq says :
-----
> 
> >> You misattribute your inability to compile the
> >> package
> > 
> > The lack of the source code of the binaries that are distributed.
> > the lack of the non system library source code that is needed to
> > produce the exe being distributed with the exe.
> > 
> >> to an alleged deliberate retention of files (so far you have
> failed
> > 
> > never said that.
> 
> You're saying it in the very same post.

What am I accusing him of? Please show me my accusations and you will
get an apology.

if accept and promote binary distros that dont live up to the GPL FAW
guidelines, then you are dependant on one persons feelings. 

That is where the problem is coming from, not from me.

> 
> [Long ranting post deleted]
> 
> You're not helping anyone with this.  The things that Hans use to
> build the
> Windows Dia are in CVS, the installer source is at sourceforge, both
> easily
> found from the Dia page.  All you've done so far is make it *more*
> difficult for people to get Dia under Windows.  I hope you're happy.

If you provide the sources for the Windows port, I will build them.
Otherwise I am working on the mingw port. I am not making anything more
difficult for anyone.

Regards,

mike

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

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

[Introspector-developers] Re: WIN32 compilation, the spirit of GNU software.

[Lars C. <lrc...@cs...>]

On Fri, 23 Aug 2002, James Michael DuPont wrote:
>  --- Cyrille Chepelov <cy...@ch...> schrieb: > Le Thu, Aug 22,
> 2002, =E0 10:08:58PM +0200, James Michael DuPont a
>> =E9crit:
>>=20
>> > Ok, so people do build windows from cvs? Anyone out there who has?
>>=20
>> Yes. Someone whom you've disgusted from distributing binaries
>> anymore.
> I mean someone besides hans.
>=20
> Has anyone here ever built it? How much time has been wasted from
> people besides myself who want to help?
>=20
> What about from scratch,without any dlls?
> did even he ever built it from scratch?=20

Why would you ever want to build it from scratch, without any dlls?  We can
hardly be required to provide build scripts for the libraries that Dia
requires.  I don't build GTK from scratch on Linux, why should I?=20=20

>> You misattribute your inability to compile the
>> package
>=20
> The lack of the source code of the binaries that are distributed.
> the lack of the non system library source code that is needed to
> produce the exe being distributed with the exe.
>=20
>> to an alleged deliberate retention of files (so far you have failed
>=20
> never said that.

You're saying it in the very same post.

[Long ranting post deleted]

You're not helping anyone with this.  The things that Hans use to build the
Windows Dia are in CVS, the installer source is at sourceforge, both easily
found from the Dia page.  All you've done so far is make it *more*
difficult for people to get Dia under Windows.  I hope you're happy.

-Lars

--=20
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H=E5rdgrim of Numenor
"I do not agree with a word that you say, but I   |------------------------=
----
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbas=
ket?

[Introspector-developers] Re: WIN32 compilation, the spirit of GNU software.

[<mdu...@ya...>]

 --- Cyrille Chepelov <cy...@ch...> schrieb: > Le Thu, Aug 22,
2002, à 10:08:58PM +0200, James Michael DuPont a
> écrit:
> 
> > Ok, so people do build windows from cvs? Anyone out there who has?
> 
> Yes. Someone whom you've disgusted from distributing binaries
> anymore.
I mean someone besides hans.

Has anyone here ever built it? How much time has been wasted from
people besides myself who want to help?

What about from scratch,without any dlls?
did even he ever built it from scratch? 
Then we should be able to get this matter resolved quickly,
otherwise you will have to wait untill my port is done.

I am committed to producing a binary with the source codes from
scratch. 
I have been reworking the autoconfication of the libiconv and gettext
under ming, Had problems getting the dll binding and making running.
When that is all working, I compile gtk... 

 
> > I still like dia and will be doing my best to make a positive
> > contribution, even if we have different interpretations of the GPL
> faq.
> > 
> > I hope that we can have peace, and work togeather.
> 
> You are talking double language here. On one hand, you sling FAQs and
> allegations about GPL violations on a software package on which you
> own no
> piece of copyright. 
I am not making any real alligations, just asking for all the source
code that makes the binary, and all the build scripts to build that
one. including the environmental settings needed. Any developer should
be able to give that and offer that under the gpl.

Am I making any allegations here? I am just exercizing my rights,
not insulting anyone.

Even if the non-english speakers here speak better english than me,
and I can be percived as antisocial, I have a right to the source code
of the gnu and gnome tools that you use to be distributed under the
rules layed out by the FSF.

For good reason they do ask us to put the source codes on the same
server, with the exact patches used to make the build.

> You misattribute your inability to compile the
> package

The lack of the source code of the binaries that are distributed.
the lack of the non system library source code that is needed to
produce the exe being distributed with the exe.

> to an alleged deliberate retention of files (so far you have failed

never said that.

> to point
> out a single missing file, despite me stating that any missing file
> would be
> involuntary, and me welcoming any bug reports so we can get this
> alleged
> missing file issue resolved). 

The missing files are the source code packages that I asked hans for,
for example. What about the source code for the dia installer,
including dia and the gnome libs, all condfigured and placed into a
directory tree that can be built?


> Not only you completely dismiss this
> good-faith, repeated call for help, but you sling even more pieces of
> FSF 
> and meta-GPL FAQs. 

I have repeated called for help to be ignored. I asked about the python
build, wanted to reproduce it. I wanted to port it to python2.2.
There is no code for all those parts either.

> 
> On the other hand, you talk about "peace, and work together".
> 
> I don't think a sane person (or a person without an agenda of
> deliberate
> bullying and pissing off others) would behave the way you have. 

Pissing people off by calling them stupid when you blatently
go against the stated standards of software distribution is useless.
I am not angry with your attempts to flame me,
because I have been insulted much worse before. So what I am a bit
insane. 

Many of the people of genius level intelligence that I have met are
bonkers. Not that I am saying that I am intellgent to make up for all
of my bad attributes. 


But I still have my rights to free software 
and I will fight for them!

Who is hoarding the gleaned secrets of the build environment to
oneself?
The exact versions of the software,the compile flags, environmental
settings, and directory layout that is needed 
to build and exe? How hard is it to just ZIP the directory and do
ones fellow developer a good deed. That is all considered to be source
code under the GPL in my humble opinion.

There are lots of people like that on the gcc list, 
just try saying that you want to extract the full parse tree and
compiler information into XML there... 

> Did CmdrTaco leave the gates of the farm open?
wow, I almost thought that was funny. 

I am going to get this thing build and check in the entire build system
to my cvs on introspector.sf.net. 

You will be able to check it out and build it from source entirly under
windows without being as super intelligent and oh so witty and friendly
as some people around here.

Others will appreciate my liberation as in freedom of the windows build
from the hands of those who do not want to share.


Remeber the hobbit, when this golum thing lost the ring, crying "Oh my
precious, gone it is..." .

I think that the build for windows is stagnating anyway,
you need more developers working on it. A COM interface is sorely
needed, and a fine tuned bonobo intergration.

Now it is time that we put this thing to the test,
I am going to get this built, and take over the windows port if hans
wants to play games and run away with the ball. We have too many people
invested in this to just play games like that.

Kindergarten is over.

I guess some people have no time  to spread around the wisdom, 
just making a simple snapshot is just too much work for a fellow
developer.

You know the GCC used to be kept in private like that, no public
developers snapshot, no public cvs and all that. It has changed 

I am going to integrate the DIA diagram editor with the VCG for graph
layout. 

I will also hook in the dll i built with perl gcc and the dotgnu cscc
c#  parser that I have been working on.

This will add on another 15 mb to the executable size, but give the
user a full c++ reverse engineering tookit with a nice GUI and
statically linked GCC inside it.

That will also resolve the conflict that I have with the gcc group and
fsf about the dynamic linking. It will give the gcc a good graph layout
to replace the non-free graphviz lib.

This might take 2-3 years to complete, but will revolutionize the gnu
software development community. I look forward to your help.

mike

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

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de

[Introspector-developers] Re: [GCC-XML]support for definitions as well as declarations?

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

--- Dale E Martin <dm...@cl...> wrote:
> I'm looking at gcc-xml because I have an interest in translating C++
> into other languages.  It looks like an excellent tool for my 
> purposes, except for the fact that method/function definitions aren't
> emitted - only the declarations.  Is there any work/attempt to
support > definitions as well?

Dale,
I have been working on the function bodies of C in the introspector,
the problem is that there are legal and moral issues attached to it. 

One of the problems with the gpl is that it is based on copyright, and
therefore exerts no control over how a program is used. Therefore the
fsf is worried that such an interface could be used to write non-free
backends on the gcc. 

Last month I met with Stallman about this issue, I understand his
concerns and am trying to figure out the best way to proceed on this
issue.

I have promised that I will remove that ability from my program, at
least for the XML side of it. On the other side, the ast-serializer and
ast-optimizer branch of the gcc are doing similar things. If you want
to help try and resolve some of the legal issues involved, I will be
willing to donate my function body dumping into gcc_xml and merge the
two projects.

But note that Stallman has said that he does not have a problem with
gccxml because of the fact that it does not dump bodies. 

On the other side, there is the cppx[1] project that does support the
full dumping of all the compiler data, but they also dont really have
any free tools for using this data, and support non-free backends. That
is why I dont use it.
 
I dont know how tenable it will be not to dump the full function body
information, because of the fact that any application (such as syntax
highlighting) depends on a full function definition. The idea from
stallman is to somehow force the developer to create the module as part
of the gcc, and therefore you would bound by the copyright/copyleft law
to re-releasing the program under the GPL. 

I am not sure how to continue on this path, except to introduce an EULA
that stipulates that the software is only usable by free software, and
that it will not be used to create non-free backends. Would you agree
to such an license? Do you think it makes sense at all.

On the other side there are very interesting programs being written as
part of the gcc itself, the deparse/ast-optimizer has a tree to c
generator, you might want to consider writing your module in c or
directly linked to the compiler as one module.
I would consider expanding my perl interface to link directly to the
gcc, and have a GCC dll/so that has the entire thing as a perl module.
This would allow a direct and static linkage of the gcc to perl and
avoid any XML.  

Of course that would again need an EULA to prevent someone from using
it for creating a non-free backend as well. As I said, if anyone is
interesting in persusing this angle, I would be willing to contribute
that part. In fact it could be added to gcc-xml, as a module........

This might come back down to a problem again, and I have to say that 
right now the best possibility to get the function bodies is from
opencxx [2].
On the other side, if you are willing to sign a form of a
non-disclosure aggreement, we can arrange a private distribution via
gpg/pgp encrypted code, but you will have to aggree not be allowed to
redistribute the code to third parties.

I hope that you found this informative, and I am looking forward to
hearing from you.
mike

[1] cppx : http://www.swag.uwaterloo.ca/~cppx/
[2] opencxx: http://www.csg.is.titech.ac.jp/~chiba/openc++.html

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

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[Introspector-developers] Status Report: CVS back up and DAML/TESTGEN being added

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

Dear All,
This is note to tell you that the introspector will be coming back
up for development, I have decided to reactivate the gcc support.

Basically the issue with the gcc is that we dont want to make it easy
to plug a compiler backend into the introspector, so the function
bodies will be reduced in content as size. Currently the complete
function body is dumped. I will be updating it to only dump a list of
things declared and used, but not the exact lines of code. 

I have been working on some daml/RDF/quads under the /daml branch
and the dotgnu/ecma/c# support in the /testgen under cvs.

The patches to Bison to dump parse tree will be put under cvs as well
in the next couple of days.

Right now it is a mess, I am just getting all the files into cvs and
then I will be cleaning them up a bit.

I will be preparing BINARIES for the following platforms 
1. cygwin
2. debian linux/x86

The following projects will be supported as input feeds in the near to
far future :
We will be defining feeds for them 
Real Soon/ASAP:
1. Gcc 3 via the bison patch, tree-dump and possibly the gcc_xml dump.
2. cscc via bison, 
3. perl via B::ToXML and Bison

Soon : 

4. Bison

Futures: 
5. DOXYGEN XML dump
6. CTAGS
7. XMI/MOF/UMLRDF
8. Make
9. Bash

If anyone using any other project/platform supported please tell me.

Regards,

Mike

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

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Re: [gxl-cpp] Re: [Introspector-developers] James Michael DuPont's proposal ... and CPPX

[Ric H. <ho...@uw...>]

Apologies again for sending this widely... I don't expect to send more.

GXL is a widely accepted XML based format for transferring data about 
graphs.  It happens to be quite handy for representing info
from GCC's symbol table for uses such as reverse engineering of C++ 
programs.  I'm hoping the Gnu people
won't be to bothered about GXL, as in essence, it's simply a data 
format. EG, see:

<a href="http://www.uni-koblenz.de/fb4/publikationen/gelbereihe/RR-1-2000/"> 
GXL: Toward A Standard Exchange Format</a>, Richard C. Holt,
Andreas Winter, Andy Schurr, 
Universitat Koblenz-Landau, Fachberichte Informatik, 1-2000,
  Universitat Koblenz-Landau, Institut fur
  Informatik, Rheinau 1, D-56075 Koblenz, May 2000,
        WCRE 2000: Working Conference on Reverse Engineering,
        Brisbane, Australia, Nov 6, 2000.

CPPX uses the dump of symbol table and semantic info from GCC, and 
transforms it to a handy form (in GXL); our main purpose
in making it available is to advance the state of the art in software 
reverse engineering --- to make it easier to mechanically
analyze C++ programs, for example, to visualize them.  In the past, 
we've used this general approach to visualize GCC, Linux,
Mozilla, VIM, etc. It seems inevitable, that this kind of research and 
this kind of tool will become mature in
the coming years.  It is my hope that FSF would be understanding and 
sympathetic to this kind of work.

I'd be very receptive to suggestions of how to help this kind of work be 
complementary to FSF and its goals.

Regards,
        Ric Holt

James Michael DuPont wrote:

>Ric,
>
>Thanks for writing back, your right, the cppx project does deserve
>mention, but I do have my reasons for not promoting and using it, and I
>will explain that later on in this mail.
>
>I wonder why there has been no announcement on the gc...@gn... mailing
>list, I have not seen an announcement there from you or Andrew, and I
>would be quite interested in their explosive reaction to the CPPX.
>As far as I know, the GCC developers are against any tools that would
>make it easier for companies to create non-free add-ons to the GCC. 
>The CPPX/GXL/SWAGKIT is a sort of "firewall" to protect you from having
>to publish your source code. 
>
>I cannot imagine that it would be supported by any free software
>developers.
>
>Note that there are more related projects, There is the
>http://public.kitware.com/GCC_XML/HTML/Index.html and
>http://gasta.sf.net/ among others that you might want to mention as
>well.
>
>Note also that I have already referenced (even if not very well) your
>project on
>http://gccintrospector.blogspot.com/2002_02_17_gccintrospector_archive.html#9963759
>Unfortunatly I have not had the time to update all the web pages with
>more than a link or two.
>
>>>The goal is to make standard and open tools for the software
>>>
>community.  Any advice on how
>
>>>best to do this welcome.  
>>>
>I think one of the first requirements for making a set of open tools is
>is ask all users to free up their source code as well, not to start
>building non-free tools tacked onto free ones. 
>
>This limitation of software used to only free software might not be
>enforcable by law : I am not a lawyer.
>
>I propose that we limit by convention and aggreement of all parties
>involved and create a truly free toolkit for software visulization,
>reengineering and program refactoring.
>
>Remember the goal of the GNU project is to create a set of free tools,
>where everyone is sharing code and has the freedom to modify them. That
>is why I do not use the CPPX/swagkit and other tools that are
>interfacing to non-free software. For me it is of importance that my
>changes to the GCC will in the long term be accepted by the GCC
>developer team and the FSF, not rejected because of a possible misuse.
>
>See this mail from Richard Stallman who I have cced, even if
>it is in the discussion of the GCC as a lib, it applies as well to the
>XML interface.
>
>http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
><!--------------------SNIP------------------------>
>Companies often try to make software non-free, and some would write
>non-free add-ons to GCC if we let them.  The reason we have free C++
>and Objective C support is because the companies which wrote these
>front ends had no *feasible* way to use them without making them part
>of GCC, where the GPL required them to be free.  It is vital that we
>preserve this situation.
>
>Anything that makes it easier to use GCC back ends without GCC front
>ends--or simply brings GCC a big step closer to a form that would make
>such usage easy--would endanger our leverage for causing new front
>ends to be free.
>
>Because of this, the GNU Project will in all probability not install
>such changes, should they be available.  This statement reflects a
>firm conclusion based on a decade of thought.
>
>I ask anyone who would like to make such changes in GCC to please
>contact me privately.  I would like to talk with you about the ideas
>you are interested in working on, to look at the magnitude of their
>potential benefits, and consider other possible ways of achieving
>them.  Please think about the importance of future free front ends,
>as well as the interest of the project you are thinking about."
><!---------------------------END SNIP------------------------>
>
>This would also apply to the CPPX and to the introspector project as
>well, that is why I have written to him and asked him for his opinion,
>and have changed my project in order to help the gcc project in total.
>
>That is one reason why I have not used the the GXL format and various
>tools, it is not clear to me what tools are free and what are not.
>
>A repository needs to be setup with a set of free tools that can be
>used in conjuction with each other, and these tools have to be usefull
>without needed to use non-free software, then it will be of benfit to
>the free software community.
>
>If the intent is to create free software, more issues need to be
>addressed, like the security of such patches.
>The possible abuse of the tree structures by non-free tools in creating
>non-free plug-ins into the gcc is one of the major concerns of the gcc
>developers and the FSF.
>
>That is why I am proposing a secure data interface layer into free
>software tools : secure being that only free software tools can access
>the data and build derived products and add-ons.
>
>It is possible to create such and interface, via a web service that has
>a click-through license, but that does not solve the problem becuase
>these patches will then not be free software anymore.
>
>The best solution is to limit the possible danger of such an interface
>to the free software community by making the interface smarter and
>containing less data. We should be working on putting more intelligence
>back into the gcc for helping with the reverse engineering tools. We
>should be exploring how an API into the internals can be statically
>linked into the GCC for allowing HIGH-SPEED and safe access into the
>parsed representation.
>
>>We are now pondering the best way to
>>license CPPX.  Its front end is a minimally modified GCC.  Its back
>>end reads data extracted by it front end.
>>
>
>My call for discussion is to address these issues and bring them to
>light, but in the end is to benefit and help the free software
>community.
>
>If we can create a consistent set of free GPLed software tools for
>reverse engineering and modern software development then all will
>benefit,
>It will encourage others to the tools and make them better if the
>source code is free and the add-ins are also free. If we support
>non-free add-ins then the chain of sharing stops and the benefits of
>free software are lost.
>
>That is why I have halted the publishing of the further interfaces into
>the GCC to explore the legal and social aspects of them, that is why I
>have called out for a discussion of these issues.
>
>Even if you may be allowed by law to do something, 
>does not mean it is right or beneficial.
>
>mike
>
>--- Ric Holt <ho...@uw...> wrote:
>
>>Hi all --- sorry for this mail to a whole list.
>>
>>Please note that work in an international community, including CSER  
>>www.cser.ca/  is working on similar problems
>>to those noted by James Michael DuPont.  Notably:
>>
>>GXL, a standardized format for such extractions:  
>>http://www.gupro.de/GXL/
>>CPPX: a GCC based front end that extracts facts from C++ programs:   
>>http://www.swag.uwaterloo.ca/~CPPX/
>>
>>The goal is to make standard and open tools for the software
>>community. 
>> Any advice on how
>>best to do this welcome.  
>>
>>We are now pondering the best way to
>>license CPPX.  Its front end is a minimally modified GCC.  Its back
>>end 
>>reads data extracted by it front end.
>>
>>Thanks,
>>        Ric Holt, Prof, Univ of Waterloo
>>(PS: Andrew Malton & Tom Dean are the brains behind CPPX).
>>
>>James Michael DuPont wrote:
>>
>>>Dear All,
>>>
>>>I am writing to you all in a call for discussion about the future of
>>>
>>>free software in the new millenium. 
>>>We are approaching the limits of the current understanding of
>>>
>>linking
>>
>>>and derived works in an networked and self descriptive systems.
>>>Where does ones creative work start and end is much more easier
>>>defined.
>>>I hope that you appreciate my humble proposal.
>>>Please feel free to respond to the mailing list
>>>int...@li.... 
>>>
>>>James Michael DuPont.
>>>
>>>-----------------------------------
>>>Here is my proposal : 
>>>-----------------------------------
>>>I propose the following API into free software development tools
>>>to be licensed for the orderly, secure, fast, and high tech buzzword
>>>compliant data backbone for a new gnu development environment.
>>>
>>>ABSTRACT
>>>
>>>The Introspector is a tool chain to extract meta-data about your
>>>programs from the compiler and present it to you for making your job
>>>
>>as
>>
>>>a programmer easier.
>>>
>>>The software is free software in the spirit of the GNU manifesto and
>>>
>>is
>>
>>>revolutionary in the freedoms that it intends on granting to its
>>>
>>users.
>>
>>>There are many many licensing and legal issues addressed by this
>>>project, and my guideline for resolving them are to limit the usage
>>>
>>of
>>
>>>the tool for non-free software if there is a need to.  The legal and
>>>licensing FAQ will be posted in the next weeks.
>>>
>>>This Meta-Data includes all data collected about your software by
>>>
>>the
>>
>>>Compiler, the Make system, the Project and Packaging system,
>>>the CVS Logs and the Mailling List.
>>>
>>>The Introspector's scope was originally just the GCC C compiler, but
>>>will be expanded to include the extraction of  meta-data from
>>>
>>different
>>
>>>compilers and interpreters.
>>>
>>>The programs meta-data will be provided as a
>>>
>>Perl/C#/(XML/RDF/DAML)/SQL
>>
>>>or plain old C/C++ interface.
>>>
>>>We will build tools to allow this meta-data to be processed by
>>>
>>various
>>
>>>GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA,
>>>
>>and
>>
>>>Editors like EMACS.
>>>
>>>Also Languge bindings like 
>>>compiling (GCC(C, C++, java) | cscc(CSHARP))
>>>scripting (guile|Python|Perl { via inline::* }|Ruby)
>>>reasoning (guile|scheme|lisp|prolog)
>>>repository (GDBM|(POSTGRES|MYSQL)XIndice)
>>>communication (soap|xmlrpc| +  a new development of a REST api)
>>>
>>>This meta-data will be stored in a repository and available to tools
>>>that need it via many different interfaces.
>>>
>>>I look forward to your comments.
>>>
>>>Please come visit my updated webpage at :
>>>http://introspector.sourceforge.net/
>>>
>>>You will find an copy of related snippets and news at :
>>>the blogger : http://gccintrospector.blogspot.com
>>>
>>>Best regards,
>>>Mike
>>>
>>>
>>>
>>>=====
>>>James Michael DuPont
>>>http://introspector.sourceforge.net/
>>>
>
>=====
>James Michael DuPont
>http://introspector.sourceforge.net/
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>
>_______________________________________________
>gxl-cpp mailing list
>gx...@rg...
>http://rgai.inf.u-szeged.hu/cgi-bin/mailman/listinfo/gxl-cpp
>

Re: [Introspector-developers] James Michael DuPont's proposal ... and CPPX

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

Ric,

Thanks for writing back, your right, the cppx project does deserve
mention, but I do have my reasons for not promoting and using it, and I
will explain that later on in this mail.

I wonder why there has been no announcement on the gc...@gn... mailing
list, I have not seen an announcement there from you or Andrew, and I
would be quite interested in their explosive reaction to the CPPX.
As far as I know, the GCC developers are against any tools that would
make it easier for companies to create non-free add-ons to the GCC. 
The CPPX/GXL/SWAGKIT is a sort of "firewall" to protect you from having
to publish your source code. 

I cannot imagine that it would be supported by any free software
developers.

Note that there are more related projects, There is the
http://public.kitware.com/GCC_XML/HTML/Index.html and
http://gasta.sf.net/ among others that you might want to mention as
well.

Note also that I have already referenced (even if not very well) your
project on
http://gccintrospector.blogspot.com/2002_02_17_gccintrospector_archive.html#9963759
Unfortunatly I have not had the time to update all the web pages with
more than a link or two.

>>The goal is to make standard and open tools for the software
community.  Any advice on how
>>best to do this welcome.  
I think one of the first requirements for making a set of open tools is
is ask all users to free up their source code as well, not to start
building non-free tools tacked onto free ones. 

This limitation of software used to only free software might not be
enforcable by law : I am not a lawyer.

I propose that we limit by convention and aggreement of all parties
involved and create a truly free toolkit for software visulization,
reengineering and program refactoring.

Remember the goal of the GNU project is to create a set of free tools,
where everyone is sharing code and has the freedom to modify them. That
is why I do not use the CPPX/swagkit and other tools that are
interfacing to non-free software. For me it is of importance that my
changes to the GCC will in the long term be accepted by the GCC
developer team and the FSF, not rejected because of a possible misuse.

See this mail from Richard Stallman who I have cced, even if
it is in the discussion of the GCC as a lib, it applies as well to the
XML interface.

http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
<!--------------------SNIP------------------------>
Companies often try to make software non-free, and some would write
non-free add-ons to GCC if we let them.  The reason we have free C++
and Objective C support is because the companies which wrote these
front ends had no *feasible* way to use them without making them part
of GCC, where the GPL required them to be free.  It is vital that we
preserve this situation.

Anything that makes it easier to use GCC back ends without GCC front
ends--or simply brings GCC a big step closer to a form that would make
such usage easy--would endanger our leverage for causing new front
ends to be free.

Because of this, the GNU Project will in all probability not install
such changes, should they be available.  This statement reflects a
firm conclusion based on a decade of thought.

I ask anyone who would like to make such changes in GCC to please
contact me privately.  I would like to talk with you about the ideas
you are interested in working on, to look at the magnitude of their
potential benefits, and consider other possible ways of achieving
them.  Please think about the importance of future free front ends,
as well as the interest of the project you are thinking about."
<!---------------------------END SNIP------------------------>

This would also apply to the CPPX and to the introspector project as
well, that is why I have written to him and asked him for his opinion,
and have changed my project in order to help the gcc project in total.

That is one reason why I have not used the the GXL format and various
tools, it is not clear to me what tools are free and what are not.

A repository needs to be setup with a set of free tools that can be
used in conjuction with each other, and these tools have to be usefull
without needed to use non-free software, then it will be of benfit to
the free software community.

If the intent is to create free software, more issues need to be
addressed, like the security of such patches.
The possible abuse of the tree structures by non-free tools in creating
non-free plug-ins into the gcc is one of the major concerns of the gcc
developers and the FSF.

That is why I am proposing a secure data interface layer into free
software tools : secure being that only free software tools can access
the data and build derived products and add-ons.

It is possible to create such and interface, via a web service that has
a click-through license, but that does not solve the problem becuase
these patches will then not be free software anymore.

The best solution is to limit the possible danger of such an interface
to the free software community by making the interface smarter and
containing less data. We should be working on putting more intelligence
back into the gcc for helping with the reverse engineering tools. We
should be exploring how an API into the internals can be statically
linked into the GCC for allowing HIGH-SPEED and safe access into the
parsed representation.

> We are now pondering the best way to
> license CPPX.  Its front end is a minimally modified GCC.  Its back
> end reads data extracted by it front end.

My call for discussion is to address these issues and bring them to
light, but in the end is to benefit and help the free software
community.

If we can create a consistent set of free GPLed software tools for
reverse engineering and modern software development then all will
benefit,
It will encourage others to the tools and make them better if the
source code is free and the add-ins are also free. If we support
non-free add-ins then the chain of sharing stops and the benefits of
free software are lost.

That is why I have halted the publishing of the further interfaces into
the GCC to explore the legal and social aspects of them, that is why I
have called out for a discussion of these issues.

Even if you may be allowed by law to do something, 
does not mean it is right or beneficial.

mike

--- Ric Holt <ho...@uw...> wrote:
> Hi all --- sorry for this mail to a whole list.
> 
> Please note that work in an international community, including CSER  
> www.cser.ca/  is working on similar problems
> to those noted by James Michael DuPont.  Notably:
> 
> GXL, a standardized format for such extractions:  
> http://www.gupro.de/GXL/
> CPPX: a GCC based front end that extracts facts from C++ programs:   
> http://www.swag.uwaterloo.ca/~CPPX/
> 
> The goal is to make standard and open tools for the software
> community. 
>  Any advice on how
> best to do this welcome.  
> 
> We are now pondering the best way to
> license CPPX.  Its front end is a minimally modified GCC.  Its back
> end 
> reads data extracted by it front end.
> 
> Thanks,
>         Ric Holt, Prof, Univ of Waterloo
> (PS: Andrew Malton & Tom Dean are the brains behind CPPX).
> 
> James Michael DuPont wrote:
> 
> >Dear All,
> >
> >I am writing to you all in a call for discussion about the future of
> 
> >free software in the new millenium. 
> >We are approaching the limits of the current understanding of
> linking
> >and derived works in an networked and self descriptive systems.
> >Where does ones creative work start and end is much more easier
> >defined.
> >I hope that you appreciate my humble proposal.
> >Please feel free to respond to the mailing list
> >int...@li.... 
> >
> >James Michael DuPont.
> >
> >-----------------------------------
> >Here is my proposal : 
> >-----------------------------------
> >I propose the following API into free software development tools
> >to be licensed for the orderly, secure, fast, and high tech buzzword
> >compliant data backbone for a new gnu development environment.
> >
> >ABSTRACT
> >
> >The Introspector is a tool chain to extract meta-data about your
> >programs from the compiler and present it to you for making your job
> as
> >a programmer easier.
> >
> >The software is free software in the spirit of the GNU manifesto and
> is
> >revolutionary in the freedoms that it intends on granting to its
> users.
> >There are many many licensing and legal issues addressed by this
> >project, and my guideline for resolving them are to limit the usage
> of
> >the tool for non-free software if there is a need to.  The legal and
> >licensing FAQ will be posted in the next weeks.
> >
> >This Meta-Data includes all data collected about your software by
> the
> >Compiler, the Make system, the Project and Packaging system,
> >the CVS Logs and the Mailling List.
> >
> >The Introspector's scope was originally just the GCC C compiler, but
> >will be expanded to include the extraction of  meta-data from
> different
> >compilers and interpreters.
> >
> >The programs meta-data will be provided as a
> Perl/C#/(XML/RDF/DAML)/SQL
> >or plain old C/C++ interface.
> >
> >We will build tools to allow this meta-data to be processed by
> various
> >GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA,
> and
> >Editors like EMACS.
> >
> >Also Languge bindings like 
> >compiling (GCC(C, C++, java) | cscc(CSHARP))
> >scripting (guile|Python|Perl { via inline::* }|Ruby)
> >reasoning (guile|scheme|lisp|prolog)
> >repository (GDBM|(POSTGRES|MYSQL)XIndice)
> >communication (soap|xmlrpc| +  a new development of a REST api)
> >
> >This meta-data will be stored in a repository and available to tools
> >that need it via many different interfaces.
> >
> >I look forward to your comments.
> >
> >Please come visit my updated webpage at :
> >http://introspector.sourceforge.net/
> >
> >You will find an copy of related snippets and news at :
> > the blogger : http://gccintrospector.blogspot.com
> >
> >Best regards,
> >Mike
> >
> >
> >
> >=====
> >James Michael DuPont
> >http://introspector.sourceforge.net/

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

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

[Introspector-developers] James Michael DuPont's proposal ... and CPPX

[Ric H. <ho...@uw...>]

Hi all --- sorry for this mail to a whole list.

Please note that work in an international community, including CSER  
www.cser.ca/  is working on similar problems
to those noted by James Michael DuPont.  Notably:

GXL, a standardized format for such extractions:   http://www.gupro.de/GXL/
CPPX: a GCC based front end that extracts facts from C++ programs:   
http://www.swag.uwaterloo.ca/~cppx/

The goal is to make standard and open tools for the software community. 
 Any advice on how
best to do this welcome.  

We are now pondering the best way to
license CPPX.  Its front end is a minimally modified GCC.  Its back end 
reads data extracted by it front end.

Thanks,
        Ric Holt, Prof, Univ of Waterloo
(PS: Andrew Malton & Tom Dean are the brains behind CPPX).

James Michael DuPont wrote:

>Dear All,
>
>I am writing to you all in a call for discussion about the future of 
>free software in the new millenium. 
>We are approaching the limits of the current understanding of linking
>and derived works in an networked and self descriptive systems.
>Where does ones creative work start and end is much more easier
>defined.
>I hope that you appreciate my humble proposal.
>Please feel free to respond to the mailing list
>int...@li.... 
>
>James Michael DuPont.
>
>-----------------------------------
>Here is my proposal : 
>-----------------------------------
>I propose the following API into free software development tools
>to be licensed for the orderly, secure, fast, and high tech buzzword
>compliant data backbone for a new gnu development environment.
>
>ABSTRACT
>
>The Introspector is a tool chain to extract meta-data about your
>programs from the compiler and present it to you for making your job as
>a programmer easier.
>
>The software is free software in the spirit of the GNU manifesto and is
>revolutionary in the freedoms that it intends on granting to its users.
>There are many many licensing and legal issues addressed by this
>project, and my guideline for resolving them are to limit the usage of
>the tool for non-free software if there is a need to.  The legal and
>licensing FAQ will be posted in the next weeks.
>
>This Meta-Data includes all data collected about your software by the
>Compiler, the Make system, the Project and Packaging system,
>the CVS Logs and the Mailling List.
>
>The Introspector's scope was originally just the GCC C compiler, but
>will be expanded to include the extraction of  meta-data from different
>compilers and interpreters.
>
>The programs meta-data will be provided as a Perl/C#/(XML/RDF/DAML)/SQL
>or plain old C/C++ interface.
>
>We will build tools to allow this meta-data to be processed by various
>GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA, and
>Editors like EMACS.
>
>Also Languge bindings like 
>compiling (gcc(C, C++, java) | cscc(CSHARP))
>scripting (guile|Python|Perl { via inline::* }|Ruby)
>reasoning (guile|scheme|lisp|prolog)
>repository (GDBM|(POSTGRES|MYSQL)XIndice)
>communication (soap|xmlrpc| +  a new development of a REST api)
>
>This meta-data will be stored in a repository and available to tools
>that need it via many different interfaces.
>
>I look forward to your comments.
>
>Please come visit my updated webpage at :
>http://introspector.sourceforge.net/
>
>You will find an copy of related snippets and news at :
> the blogger : http://gccintrospector.blogspot.com
>
>Best regards,
>Mike
>
>
>
>=====
>James Michael DuPont
>http://introspector.sourceforge.net/
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com
>
>
> ------------------------------------------------------------------------
>
> Subject:
>
> Proposal for an Worldwide Data Introspector API layer for GNU tools.
> From:
>
> James Michael DuPont <mdu...@ya...>
> Date:
>
> Sat, 29 Jun 2002 10:50:29 -0700 (PDT)
> To:
>
> gnu...@gn...
>
>
>-----------------------------------
>Here is my proposal : 
>-----------------------------------
>I propose the following API into free software development tools
>to be licensed for the orderly, secure, fast, and high tech buzzword
>compliant data backbone for a new gnu development environment.
>
>ABSTRACT
>
>The Introspector is a tool chain to extract meta-data about your
>programs from the compiler and present it to you for making your job as
>a programmer easier.
>
>The software is free software in the spirit of the GNU manifesto and is
>revolutionary in the freedoms that it intends on granting to its users.
>There are many many licensing and legal issues addressed by this
>project, and my guideline for resolving them are to limit the usage of
>the tool for non-free software if there is a need to.  The legal and
>licensing FAQ will be posted in the next weeks.
>
>This Meta-Data includes all data collected about your software by the
>Compiler, the Make system, the Project and Packaging system,
>the CVS Logs and the Mailling List.
>
>The Introspector's scope was originally just the GCC C compiler, but
>will be expanded to include the extraction of  meta-data from different
>compilers and interpreters.
>
>The programs meta-data will be provided as a Perl/C#/(XML/RDF/DAML)/SQL
>or plain old C/C++ interface.
>
>We will build tools to allow this meta-data to be processed by various
>GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA, and
>Editors like EMACS.
>
>Also Languge bindings like 
>compiling (gcc(C, C++, java) | cscc(CSHARP))
>scripting (guile|Python|Perl { via inline::* }|Ruby)
>reasoning (guile|scheme|lisp|prolog)
>repository (GDBM|(POSTGRES|MYSQL)XIndice)
>communication (soap|xmlrpc| +  a new development of a REST api)
>
>This meta-data will be stored in a repository and available to tools
>that need it via many different interfaces.
>
>I look forward to your comments.
>
>Please come visit my updated webpage at :
> http://introspector.sf.net
>
>You will find an copy of related snippets and news at :
> the blogger : http://gccintrospector.blogspot.com
>
>Best regards,
>Mike
>
>
>=====
>James Michael DuPont
>http://introspector.sourceforge.net/
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com
>
>_______________________________________________
>Gnu-misc-discuss mailing list
>Gnu...@gn...
>http://mail.gnu.org/mailman/listinfo/gnu-misc-discuss
>

[Introspector-developers] Welcome to introspector developers list

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

I noticed that you have subscribed,
and just wanted to say hi!

please you can tell me what brought you here and what your interests
are. 

I just had a meeting with RMS yesterday about the future of the
introspector project. He said that it will be possible to create an API
that is not dangerous or worrysome.

The first step will be to modify the gcc interface to not output all of
the treenodes from the gcc, but to make the output smaller and more
intelligent, if function body parsing is needed, we can always invoke a
new instance of the compiler with the precompiled headers and then we
can just parse the function needed. 

Maybe you have some ideas?

mike

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

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

[Introspector-developers] Fwd: Re: Proposal for an Worldwide Data Introspector XML/RDF API layer for software.

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

--- Sergey Melnik <me...@db...> wrote:
> Date: Mon, 01 Jul 2002 17:00:59 +0200
> From: Sergey Melnik <me...@db...>
> To: James Michael DuPont <mdu...@ya...>
> CC: Dan...@br..., www...@w3...
> Subject: Re: Proposal for an Worldwide Data Introspector XML/RDF API
> layer for software.
> 
> Mike,
> 
> thank you for drawing our attention to your project. Indeed, metadata
> 
> management poses one of the major challenges for the state-of-the-art
> 
> software engineering. I'm confident that using a right mix of UML,
> RDF 
> and XML could be beneficial for the kind of tools and scenarios that
> you 
> describe.
> 
> I'm looking forward to hearing about your progress.
> 
> Best,
> Sergey
> 
> 
> James Michael DuPont wrote:
> 
> > Dear All,
> > 
> > My name is James Michael DuPont, and am new to the RDF list.
> > I have been working on my free time in the past two years on XML
> > interfaces into Free software.
> > 
> > I have noticed your interesting discussion of UML,XMI and RDF.
> > That is why I am writing to you all in a call for discussion about
> the
> > future of SoftwareMetadata exchange in the new millennium. 
> > Currently I am working on XML interfaces into GCC, BISON and Perl
> with
> > the goal of creating a standard software meta-data exchange format.
> 
> > The great thing about free software that allows for access to the
> > source code is that it can be patched easily given a introspector
> > library. Of course this will not preclude others from using this
> data
> > format and data, per say, even if there will be limits to the
> secure
> > access to some data from free software via a secure web service.
> > 
> > Your work on RDF, UML and DAML has been a real inspiration for me,
> and
> > I am interested in using the great work that you have been doing.
> > 
> > We are approaching the limits of the current understanding of
> linking
> > and derived works in an networked and self descriptive systems, the
> GPL
> > covers copyright, but not the output of the software.
> > However, Where does ones creative work start and end is much more
> > easier
> > defined. 
> > Given a secure network invocation provided by a authenticating web
> > service, we should be able to limit the possibility of abuse of
> this
> > data, while providing an open standard.
> > 
> > I hope that you appreciate my humble proposal.
> > 
> > Note that I do have running code and examples, 
> > I have already XMLized all of the code GCC via a bootstrap, and am
> > working on ECMA344(CSHARP) support via the DOTGNU project.
> > 
> > The (XML/RDF)ization of BISON will provide a good starting point
> for
> > creating ONTOLOGIEs out of existing grammars.
> > 
> > Please feel free to respond to the mailing list
> > int...@li.... 
> > 
> > James Michael DuPont.
> > 
> > -----------------------------------
> > Here is my proposal : 
> > -----------------------------------
> > I propose the following API into free software development tools
> > to be licensed for the orderly, secure, fast, and high tech
> buzzword
> > compliant data backbone for a new gnu development environment.
> > 
> > ABSTRACT
> > 
> > The Introspector is a tool chain to extract meta-data about your
> > programs from the compiler and present it to you for making your
> job as
> > a programmer easier.
> > 
> > The software is free software in the spirit of the GNU manifesto
> and is
> > revolutionary in the freedoms that it intends on granting to its
> users.
> > There are many many licensing and legal issues addressed by this
> > project, and my guideline for resolving them are to limit the usage
> of
> > the tool for non-free software if there is a need to.  The legal
> and
> > licensing FAQ will be posted in the next weeks.
> > 
> > This Meta-Data includes all data collected about your software by
> the
> > Compiler, the Make system, the Project and Packaging system,
> > the CVS Logs and the Mailing List.
> > 
> > The Introspector's scope was originally just the GCC C compiler,
> but
> > will be expanded to include the extraction of  meta-data from
> different
> > compilers and interpreters.
> > 
> > The programs meta-data will be provided as a
> Perl/C#/(XML/RDF/DAML)/SQL
> > or plain old C/C++ interface.
> > 
> > We will build tools to allow this meta-data to be processed by
> various
> > GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA,
> and
> > Editors like EMACS.
> > 
> > Also Language bindings like 
> > compiling (gcc(C, C++, java) | cscc(CSHARP))
> > scripting (guile|Python|Perl { via inline::* }|Ruby)
> > reasoning (guile|scheme|lisp|prolog)
> > repository (GDBM|(POSTGRES|MYSQL)XIndice)
> > communication (soap|xmlrpc| +  a new development of a REST api)
> > 
> > This meta-data will be stored in a repository and available to
> tools
> > that need it via many different interfaces.
> > 
> > I look forward to your comments.
> > 
> > Please come visit my updated webpage at :
> > http://introspector.sourceforge.net/
> > 
> > You will find an copy of related snippets and news at :
> >  the blogger : http://gccintrospector.blogspot.com
> > 
> > Best regards,
> > Mike
> > 
> > 
> > =====
> > James Michael DuPont
> > http://introspector.sourceforge.net/
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> > 
> > 
> 
> 


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

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Introspector-developers] Fwd: Proposal for an Worldwide Data Introspector API layer for GNU tools.

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

Dear All,

I am writing to you all in a call for discussion about the future of 
free software in the new millenium. 
We are approaching the limits of the current understanding of linking
and derived works in an networked and self descriptive systems.
Where does ones creative work start and end is much more easier
defined.
I hope that you appreciate my humble proposal.
Please feel free to respond to the mailing list
int...@li.... 

James Michael DuPont.

-----------------------------------
Here is my proposal : 
-----------------------------------
I propose the following API into free software development tools
to be licensed for the orderly, secure, fast, and high tech buzzword
compliant data backbone for a new gnu development environment.

ABSTRACT

The Introspector is a tool chain to extract meta-data about your
programs from the compiler and present it to you for making your job as
a programmer easier.

The software is free software in the spirit of the GNU manifesto and is
revolutionary in the freedoms that it intends on granting to its users.
There are many many licensing and legal issues addressed by this
project, and my guideline for resolving them are to limit the usage of
the tool for non-free software if there is a need to.  The legal and
licensing FAQ will be posted in the next weeks.

This Meta-Data includes all data collected about your software by the
Compiler, the Make system, the Project and Packaging system,
the CVS Logs and the Mailling List.

The Introspector's scope was originally just the GCC C compiler, but
will be expanded to include the extraction of  meta-data from different
compilers and interpreters.

The programs meta-data will be provided as a Perl/C#/(XML/RDF/DAML)/SQL
or plain old C/C++ interface.

We will build tools to allow this meta-data to be processed by various
GUI tools, Graph Layout Tools like VCG, Diagram Editors like DIA, and
Editors like EMACS.

Also Languge bindings like 
compiling (gcc(C, C++, java) | cscc(CSHARP))
scripting (guile|Python|Perl { via inline::* }|Ruby)
reasoning (guile|scheme|lisp|prolog)
repository (GDBM|(POSTGRES|MYSQL)XIndice)
communication (soap|xmlrpc| +  a new development of a REST api)

This meta-data will be stored in a repository and available to tools
that need it via many different interfaces.

I look forward to your comments.

Please come visit my updated webpage at :
http://introspector.sourceforge.net/

You will find an copy of related snippets and news at :
 the blogger : http://gccintrospector.blogspot.com

Best regards,
Mike



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

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Introspector-developers] Re: [DotGNU]Proposal for a introspector API into free software development toolchain

[Paul K. <ni...@ar...>]

Could you please remove this discussion from the gcc list, because it
has already been clearly stated that it does NOT belong there?

Thanks,
	paul