Live data from Hacker News

Who needs Graphviz when you can build it yourself?

spidermonkey.dev

101–110 of 114 posts

Re: Who needs Graphviz when you can build it yourself?

#101
post #67

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.

The issue is to make sense of the incredibly detailed AST to answer various questions about the code base. For example, how to make an information flow graph that shows what functions read and write what variables in a set of C++ classes.

Re: Who needs Graphviz when you can build it yourself?

#102
One of the nice things about this work is that by assuming the environment is a web client, it supports some basic interactive exploration, and offloads a lot of bothersome rendering problems.

Also, 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?

#104
I feel like going to the source of an algorithm/implementation is a super power, as illustrated by this example.

Having 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?

#105
post #48

Earlier 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…

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.

Re: Who needs Graphviz when you can build it yourself?

#106
post #81
post #60

Earlier 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.

Various tools use tool-specific graph attributes. For example, "rank" and "minlen" mean something to the hierarchical or layered graph layout tool (dot) but not to other layout tools. "size" and "label" are the same in all the layout tools. They all use the same underlying graph representation library with a parser generated by yacc or bison.

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?

#107
post #48

Earlier 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.

True, and in fact I am aware that other teams look for paid solutions where graphs power the core features of their products. For us, it is a small feature, so we were looking for the "least trouble" path.

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?

#108

Earlier 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…

There are also a bunch more available information channels that this doesn’t use that could communicate more information. Color, shape, pattern line type, “backdrops”/groups could all be implemented to provide additional visual clarity on any range of parameters you might care about.

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?

#109
post #19

To 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.

What I really like about the article is the reflection on the limits of optimization. Optimization gets you mostly OK results most of the time, but there will always be pathological cases where optimization gives you bad results, and there’s often room for drastic improvements of you’re allowed to make stronger assumptions.

Re: Who needs Graphviz when you can build it yourself?

#110
post #58
post #2

This 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.

Can you please link to your thesis? This sounds very interesting.
Post reply on HN