Cool! Will it emulate/recreate any of the other engines (neato, etc.)?
Show HN: A Graphviz Implementation in Rust
11–20 of 56 posts
Re: Show HN: A Graphviz Implementation in Rust
#12Does 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).
> lack of manual formatting controls
What do you mean? You can always specify the exact coordinates of some vertices:
3 [pos="20,30"]
Re: Show HN: A Graphviz Implementation in Rust
#13I 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
> 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.
Re: Show HN: A Graphviz Implementation in Rust
#14Nice! 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.
Re: Show HN: A Graphviz Implementation in Rust
#15This 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
Re: Show HN: A Graphviz Implementation in Rust
#16This 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…
It sounds like your rust is too old. IIRC the array FromIterator is only a month or two old.
Re: Show HN: A Graphviz Implementation in Rust
#17How 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.
Re: Show HN: A Graphviz Implementation in Rust
#18No post body was provided.
Re: Show HN: A Graphviz Implementation in Rust
#19Don't know if it's a standard Graphviz thing but the text felt like it wasn't vertically centered in the bubble's.
Re: Show HN: A Graphviz Implementation in Rust
#20Does 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).
> 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.
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.