Closed rodinhart closed 5 years ago
hi @rodinhart - below the waterline state-machine-cat uses viz.js (which is graphviz, compiled to javascript) by default for generate the svg. it's viz.js that emits this error message.
dot
one, fdp
(which should be better suited for bigger graphs) and osage
algorithms work:
smcat --engine fdp yourstatemachine.smcat
or
smcat --engine osage yourstatemachine.smcat
You can also play around with these in the hamburger menu on the demo website (https://state-machine-cat.js.org)
smcat --output-type dot yourstatemachine.smcat | dot -T svg > yourstatemachine.svg
fdp
and sometimes with osage
support as well - replace dot -T svg
above with dot -T svg -Kfdp
to try it in the native version)I agree b.t.w. about the (lack of) clarity of the error message - I'll see if I can at least put some context to it before passing it on to output.
=> I'm b.t.w. very interested in sizeable (and big / humongous) charts to include them in my automated tests. I'll understand if you can't share your state machine description - but if you can it would be helpful (and maybe I can tweak something in the dot state-machine-cat generates so it does work when I have a real life sample...)
Hallo @sverweij , thank you for the extensive response! My response to your response in order:
I will try the different layouts and see how they do. The default dot
is definitely the one that I'm after, as it seems the clearest, and closest to Harel's diagrams.
I will definitely try using graphviz directly, this will hopefully allow me to tweak a few things which would be perfect.
Re low memory replacement for graphviz: understood, I appreciate the difficulty of putting something appropriate in place.
Re new version of viz.js. Also understood, we've all been there.
Finally, I will try to get an anonymized version of the statechart to you for testing purposes.
Thanks again.
FYI: I've made a minimal reproduction sample - it seems the nesting depth is quite memory intensive for the dot
algorithm. fdp
and osage
handle it better. They also yield nicer looking diagrams (see below - for smaller/ less deeply nested diagrams this is not typically true...)
dot
format, but wasn't able to make viz.js (or the native gv for bigger graphs) happy yet - but I do have one or two tricks that could work ...a {
aa {
aaa {
aaaa {
aaaaa {
aaaaaa {
aaaaaaa {
aaaaaaaa {
aaaaaaaaa => aaaaaaaab;
aaaaaaaaa => aaaaaaaac;
aaaaaaaac => aaaaaaaad;
};
};
};
};
};
};
};
};
😬
Brilliant!
Both fdo and osaga manage to produce a chart, but in my case a lot of the transition go wildly across the diagram. Also, some transition meet not at the edge of a node, but somewhere in white-space. dot seems to be better suited (if we can get it to run).
I still want to try graphviz directly, just to see what happens.
graphviz works!
thanks for the _statemachine.txt - helpfull!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
I am trying to visualise a fairly sizable statechart (maybe 50 states, with 7 levels deep nesting), but get an error when going beyond level 5.
Expected Behavior
Expect the SVG to be produced.
Current Behavior
Possible Solution
Increase allocated memory, or provide more detailed error logging why it runs out? Perhaps a small tweak to the statechart will prevent the engine from choking?
Steps to Reproduce (for bugs)
Context
I'm just trying to find a good visualizer for our statechart, most importantly one that is stable (in its layout).
Your Environment