Had an original SE as banking backup. Recently the banking app demanded a newer iOS after being updated. Now that good old little device that was supposed to save me eventually is basically bricked for me.
I'd briefly come across Elk, but couldn't tell how it was better than what I was using. The examples I could find all showed far simpler graphs than what we had, and nothing that seemed to address the problems we had, but maybe I should give it another look, because I've kinda lost faith that dagre is going to do what we need.
If I can explain briefly what our issue is: we've got a really complex graph, and need to show it in a way that makes it easy to understand. That by itself might be a lost cause already, but we need it fixed. The problem is that our graph has cycles, and dagre is designed for DAGs; directed acyclic graphs. Fortunately it has a step that removes cycles, but it does that fairly randomly, and that can sometimes dramatically change the shape of the graph by creating unintentional start or end nodes.
I had a way to fix that, but even with that, it's still really hard to understand the graph. We need to cut it up into parts, group nodes together based on shared properties, and that's not something dagre does at all. I'm currently looking into cola with its constraints. But I'll take another look at elk.
Our graphs are hierarchical, can contain cycles, too and have a bunch of directed subgraphs. We reach 500 nodes with 20k ports and 10k edges and "getting the graph" is still possible but takes a bit of practice. Cycle breaking is okish for us, because there is a strong asymmetry between many "forward" and much less "backwards" edges that makes the heuristics succeed often.
The biggest improvement for us was deduplication by using generators an referencing already emitted objects. Don't run flatc on a JSON, it doesn't do that.
Testing is answering "does it do, what it is supposed to do?" and autonomous means "according to it's own law(s)". Sounds like a contradiction to me. I'd answer with "none".
One can define properties the software is supposed to have, then autonomously test for those properties (as in, initiate a process that spends arbitrary amounts of time running new tests to try to show the software fails to have those properties.)
Is this not autonomous because the properties weren't created without humans being involved? How could that even be possible?
For profiling I like the dual representation of treemap and tree of https://kcachegrind.github.io/html/Home.html a lot. Addresses the criticized points of treemaps of the post (see percentage and estimate areas of sub-trees) better than the examples chosen there.
Using this as well in embddded. The whole point is to commit and lock the pages after allocation, to not experience what you correctly describe. You want to have a single checkpoint after which you simply can stop worrying about oom.
The most important thing IMHO is to "rotate the structure 90 degrees" from package to function. You start with "all files of one package" and get "all files of all packages, that serve the same purpose" like for example all includes, all man pages, all binaries. This simplifies and speeds up a system, as you only need one or a low number of paths per function.
reply