Re: XML dumping and GraphViz/VCG in the GCC ast-optimizer-branch

[James Michael DuPont <mdupont777 at yahoo dot com>]

--- Joe Buck <jbuck@synopsys.com> wrote:
> James Michael DuPont writes:
> 
> > Also RMS has supported my fight with the University of Saarland
> that
> > tried to block the release of the uglified parts of the vcg tool. 
> > 
> > I now have that non-uglified code from the author and will be
> > re-releasing VCG as a GNU project later on when I find some time.
> 
> This is great news and would be a huge contribution to the free
> software
> world, especially if it reads graphviz format.

Thanks Joe.
It means alot to me.

I see the vcg as an important tool to help understand programs.

Now, if we look at the problem of communication, how can the gcc safely

communicate the asts to the vcg for layout. 

You will see that any form of communcation is subject to a
man-in-the-middle attack that can dump the data out to a pipe.

Now you also need the ability to focus the results on something
visible,
to search and filter the ast nodes. Others will want to transform the
trees selecting certain attributes and turning those into graph nodes.

If the asts are put into an libxml dom structure, those transformations
can be done by a simple xslt style sheet, or perl script linked in, and
the passed on to the visualizer, all without leaving main memory.

So you see that to do anything usefull with this information, it must
run the risk to be intercepted.

Now, I am not a laywer, but 
I think that if we can show that if the data is put into such a form
that it is indended for transport between modules, and a third party
takes that data a runs off with it, we can then say that they got
between two statically linked modules . Maybe that will offer some
protection against non-free modules getting in between?

But on the other hand, what if you take these graphs and run the
through some 3d transformations on your video card, to use the
accelerated chips for doing things like that. It could very well be
non-free software, so what about that?

> > > Especially on side branches, you should assume that anything
> there is
> > > experimental and not necessarily accepted for release. 
> > > Non-acceptance
> > > might be based on technical reasons or policy reasons.
> > 
> > Fine, then you wont have any problem with me branching the
> > ast-optimizer branch and maintaining that Branch for visualization.
> 
> Ah, the argument from precedent again!  *I* have no problem, and if
> you're
> in regular communication with RMS then you'll know whether or not
> *he* has
> a problem, but of course there's a strong difference between "I don't
> like
> it" and "I'm going to try to stop you" and I suspect that his
> feelings
> will be more in the former category.
Fine, and that was got me into problems before. 
It is easier to ask for forgiveness than for permission.

I will be branching the code, like it or not. I will be updating it
regulary from the gcc base. 

mike

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

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