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
>