[HN Gopher] Show HN: A Graphviz Implementation in Rust
___________________________________________________________________
Show HN: A Graphviz Implementation in Rust
Author : Q26124
Score : 109 points
Date : 2022-03-17 19:48 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fibonacci112358 wrote:
| How is performance compared to Graphviz? There are some large
| compiler Control flow graphs with 500+ nodes where Graphviz
| really starts to take a long time to build a layout (dozens of
| seconds or worse). Profiling dot a bit, saw that most time was
| spent doing some DFS, and a lot of the data structs seem to be
| linked lists, the opposite of cache friendly.
| billconan wrote:
| this is very nice! what license will it have?
| Q26124 wrote:
| I'll pick one of the open source licenses once the project is
| more useful.
| [deleted]
| nikeee wrote:
| Author of a web-based GraphViz editor [1] here. We're currently
| using viz.js [2], which is the original GraphViz compiled to
| WASM. Since viz.js is unmaintained, we're looking for a
| replacement.
|
| This library looks really promising! As it's written in rust, it
| should be possible to port it to WASM. Are there plans in that
| direction?
|
| Is it planned to be a drop-in replacement for GraphViz (or the
| dot engine)?
|
| [1]: https://edotor.net [2]: https://github.com/mdaines/viz.js
| godisdad wrote:
| I have always loved graphviz/dot and watching the rise of mermaid
| and other tools is encouraging that there's more competition in
| the ecosystem.
|
| But man, endlessly fiddling to fix the layouts is time I'd like
| back in my life
| Someone wrote:
| > But man, endlessly fiddling to fix the layouts is time I'd
| like back in my life
|
| I know many engineers are perfectionists, but pick your
| battles. It's not as if the alternative of manually laying out
| every node and edge and maintaining it is universally better.
| zackees wrote:
| Would be interesting to compile it to wasm and see how it
| performs against graphviz.asm.js in the browser:
|
| http://webgraphviz.com/
| deaddabe wrote:
| Why imply WASM and a browser? I guess running a benchmark of
| the two binaries on a host should be sufficient.
| jcelerier wrote:
| abstractions will continue until morale improves
| steveroush wrote:
| Cool! Will it emulate/recreate any of the other engines (neato,
| etc.)?
| wswope wrote:
| Does the standard implementation include any similar debug
| rendering? Seems like the coolest part of the project!
|
| I tend to stay away from Graphviz a lot more than I otherwise
| would these days due to the lack of manual formatting controls
| (have spent waaaayyy too many hours writing code to add invisible
| edges between certain nodes to force row-ordered layouts).
| Q26124 wrote:
| The standard implementation does not have debug mode. Reverse
| engineering GV by reading the 90's style c code is not fun
| either.
| jrockway wrote:
| Hah, that's hilarious. I also like graphs but hate manually
| laying them out, so I always use Graphviz and live with the
| results. Sometimes I think I could do better, but typing "foo
| -> bar" a few times is so much easier than spending any time
| thinking about what would look nicest. One time I added colors
| though, that was kind of nice.
| tejtm wrote:
| yep exactly. paraphrasing something I read somewhere ...
|
| "Best to think of Graphviz as a competent but unruly
| teenager"
|
| and then just be glad you did not have to do the work
| yourself.
| enriquto wrote:
| > lack of manual formatting controls
|
| What do you mean? You can always specify the exact coordinates
| of some vertices: 3 [pos="20,30"]
|
| This line of code, anywhere within your graph specification,
| forces vertex 3 to be placed at position (20,30). It doesn't
| get more manual than that.
| wswope wrote:
| Have you tried it before?
|
| Pos doesn't work with most layout engines (most notably dot),
| making it kinda useless, and graphviz doesn't easily expose
| the dimensions of a node to accommodate dynamic layout. You
| can work around that, but that's nowhere near as ergonomic as
| some sort of "tree level"-like argument that would force a
| node to position at a certain Y-coord while leaving the
| automatic layout process otherwise intact.
| lambda_dn wrote:
| I feel the new hot thing is X implemented in Rust.
| xcambar wrote:
| Anything reimplemented in whatever is the trend-du-jour is
| boring, I agree.
|
| I tried to find exceptions but couldn't.
| jcims wrote:
| Nice! The general pattern I've encountered with graphviz is to
| start with it and hope you're done before it starts segfaulting
| on your data. Would be interesting to see if this helps.
|
| One of the things I rarely see in other graphing tools is the
| concept of node clusters. Super helpful in a bunch of situations
| I've encountered and wish it was more broadly implemented in
| other layout engines.
| jll29 wrote:
| This does not seem to compile: -->
| src/core/color.rs:180:21 | 180 | for pair
| in KNOWN_COLORS { | ^^^^^^^^^^^^
| borrow the array with `&` or call `.iter()` on it to iterate over
| it | = help: the trait `Iterator` is not
| implemented for `[(&str, u32); 148]` ...
| error[E0277]: `[geometry::Point; 20]` is not an iterator
| --> src/topo/placer/edge_fixer.rs:272:39 | 272 |
| for offset in offsets { |
| ^^^^^^^ borrow the array with `&` or call `.iter()` on it to
| iterate over it
|
| Do I need a specific version of Rust, perhaps?
| kevincox wrote:
| It sounds like your rust is too old. IIRC the array
| FromIterator is only a month or two old.
| ZeroGravitas wrote:
| Don't know if it's a standard Graphviz thing but the text felt
| like it wasn't vertically centered in the bubble's.
___________________________________________________________________
(page generated 2022-03-17 23:00 UTC)