Earlier quoted context omitted.
If you can get the AST output into a text file, then it should be easy to convert it to the DOT input that GraphViz takes, which at heart is just a list of node connections (A -> B).
"clang -Xclang -ast-dump=json" will take you partway there.
Who needs Graphviz when you can build it yourself?
101–110 of 114 posts
Re: Who needs Graphviz when you can build it yourself?
#102Also, by focusing on control flow graphs, the proposed method does a better job with domain-specific layout. Apparently CFG visualization and exploration is a current topic; e.g. CFGExplorer. Probably Graphviz some users would benefit if it incorporated CFG-friendly level assignment as an option.
There's already machinery in Graphviz to support polylines instead of splines, and to control edge ordering, but it is not well tested or documented. It seems tempting to incorporate an edge routing algorithm of Brandes and Kopf, based on long vertical runs with at most 2 bends per edge. This seems close to a master's degree worth of work to understand and implement.
Graphviz started almost 40 years ago, is only supported by a few (one or two?) 2nd-generation volunteers with no 3rd generation on the scene yet. Over the years we've had plenty of our own disdainful "What is all this junk" moments, about our own code and other people's (c.f. various xkcd comics), but sometimes a better perspective is asking "What is being optimized that led to some team choosing or ending up at this point in the design space". Generally, the market is addicted to features.
It is a little dismaying to see the relatively slow progress in the broad field of declarative 2d diagramming. Given the way the pendulum has swung so hard back toward language based methods and away from using interaction to do everything, you'd think there would be a bigger payoff now for doing the work. Unfortuantely tool-making has always been a tough market. The customers are generally smart, demanding, and work in cost centers so don't have generous budgets.
Re: Who needs Graphviz when you can build it yourself?
#103Re: Who needs Graphviz when you can build it yourself?
#104Having used Graphviz for fairly complex visualizations I was initially shocked that someone would rewrite it themselves. Then I saw the breakdown of the algorithm and realized it may not be as complicated as I first thought.
All that being said, as a general rule it is hard to know what the hidden complexities may be until you are finished implementing the algorithm.
Re: Who needs Graphviz when you can build it yourself?
#105Earlier quoted context omitted.
Interesting. The wiki says: "The Eclipse Public License is designed to be a business-friendly free software license, and features weaker copyleft provisions than licenses such as the GNU General Public License (GPL)."
Well, it's just they think it's business-friendly. From EPL: > If a Contributor Distributes the Program in any form, then: a) the Program must also be made available as Source Code, in accordance with section 3.2 ... Except in startups that really embrace the idea of open source, no "serious" company will offer any portion of their source code under EPL license, even if that's just the modified/derived part of it. No…
Isn't the EPL "weak copyleft", so LGPL-ish? Would companies raise similar issues about glibc and GNU libstdc++? Just curious.
Re: Who needs Graphviz when you can build it yourself?
#106Earlier quoted context omitted.
> Each engine has its own DSL, basically. Does it? There are slightly different DSLs for directed and non-directed graphs, some features only work with some output formats, but AFAIK, everything in the DSL in independent of the layout engine.
Looking at the docs again with fresh eyes, I think you and fulafel are on the money. The specific engine syntaxes are by & large mutually incompatible, but DOT does seem to be the label used for the overall lang as well as the dot-engine-compatible dialect.
The documentation includes a big table of attributes that graphviz tools recognize.
With the availability of LLMs, there is better automated support now to find features that are needed. Just imagining here, but "make the layout fill the available space" or "make all the nodes look like points with associated text labels" (not sure if that even works but it should).
Re: Who needs Graphviz when you can build it yourself?
#107Earlier quoted context omitted.
Well, it's just they think it's business-friendly. From EPL: > If a Contributor Distributes the Program in any form, then: a) the Program must also be made available as Source Code, in accordance with section 3.2 ... Except in startups that really embrace the idea of open source, no "serious" company will offer any portion of their source code under EPL license, even if that's just the modified/derived part of it. No…
Don't most companies seek a supported product, like yWorks or Tom Sawyer Software in the case of graph layout? Isn't the EPL "weak copyleft", so LGPL-ish? Would companies raise similar issues about glibc and GNU libstdc++? Just curious.
I don't know enough about all those other libraries and their licenses, but I do know that as long as we don't ship those libraries, especially modified versions, it's likely ok (of course that's simplified). Some internal tooling depends on GNU tools but we are just users. For things like glibc, it's just a standard system library, so linking with it is not a problem. (I am sure legal has looked at this.)
But GPL/LGPL software is definitely the minority of software we use in any way. Basically they need to be avoided as much as possible.
Re: Who needs Graphviz when you can build it yourself?
#108Earlier quoted context omitted.
I’m not sure how far you can push the generality of the iongraph algorithm. My gut is that it could be made to work somewhat well for any control flow graph with reducible control flow, but I expect there would be many complications.
To get more precise, we benefit from knowing the nesting depth of each block. This plus reducible control flow is enough to reliably find loops. We also know exactly which edges are loop backedges; it’s easiest when these are explicitly annotated but perhaps it would be possible to derive that info from other loop info. (In Ion we have a dedicated “backedge block” per loop, which makes it obvious what we should do, b…
I used to use the dcc application Nuke and it had some very complex graphs but the different nodes were all color coded so zooming out you could get a good idea of what was happening where just from the average color of a section.
It didn’t have an auto layout algo as good as this though.
Re: Who needs Graphviz when you can build it yourself?
#109To be more accurate, the comparison is not with Graphviz, but with dot(1). Graphviz is a visualization framework and it includes many layout engines, implementing different algorithms: dot, neato, fdp, sfdp, circo, twopi, ... It would be great if this new custom algorithm were to be contributed to Graphviz.
I’m not sure how far you can push the generality of the iongraph algorithm. My gut is that it could be made to work somewhat well for any control flow graph with reducible control flow, but I expect there would be many complications.
Re: Who needs Graphviz when you can build it yourself?
#110This is a cool example of how specializing a generic algorithm to a specific subspace can yield much better results. This is quite often the case in my experience, but we often don't bother utilizing properties that are specific to our problem space, and just apply the generic algorithm out of convenience (and because it is often good enough)
I wrote my thesis on this! Application-specific system design can get you orders of magnitude performance improvement, as well as better scalability/fault tolerance properties. I focused on graph analytics, but it's reasonable to think it applies more broadly. Definitely true that application-specific design is often not worth the investment though. Chasing that 1000x improvement can easily cost you a year or two.