Hacker News Reader

Comment by zvr | Hacker News Reader

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.

View on HN

It's a bit confusing. Dot apparently is both the language name [1] for the Graphviz syntax, and one of the layout engines [2], possibly with different capitalizations.

[1] https://graphviz.org/doc/info/lang.html [2] https://graphviz.org/docs/layouts/dot/

I've used GraphViz/Dot (I call `dot` in my terminal, but the package to install is `graphviz`) for probably two decades at this point, and what is what is still not clear to me, kind of like the whole imagemagick/convert thing which is similar, at least to someone on the outside.

Not sure why they can't come up with new names, use those, then when you invoke the program in the terminal, call the binary the same thing, instead of mucking about with calling everything differently, except some things, that share names.

> Not sure why they can't ...

This is exactly what they have done. You can call "dot" and it runs the dot layout engine, but you can also run "neato", "sfdp" or any other -- with the same input.

The "graphviz" package installs all these executables.

At least Imagemagick came to their senses and renamed their command to magick (with convert still aliased for BC).

I can see how you got that impression and don’t fault you for it in the slightest, but that’s not accurate.

It’s not the language name for all Graphviz syntax; it’s only the syntax for renderings made with the dot engine. Each engine has its own DSL, basically.

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

You can also set:

    layout = neato;

in a dot file, call dot, and it will use the neato layout engine.

(See https://graphviz.org/docs/attrs/layout/)

And if I look in my /usr/bin, I see that neato is just symlinked to dot. It's pulling the usual trick of one executable that behaves slightly differently depending on the invocation name.

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

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, but which other compilers likely wouldn’t have.)

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.

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.

Yes, that would be great. Iongraph is MPL, graphviz is EPL. But Iongraph is Javascript anyway, so you would need to use Claude to translate it to C

Why would you need Claude for that?

Everyone knows it is impossible to translate 1000 lines of JS to C in a reasonable amount of time. I mean, 1000 lines is kind of a lot, you know?

"Need" is a bad word ... and ymmv

Kimi is also good. New habits, you know

Reply on news.ycombinator.com