Bradley Kemp

Functional configuration

6

There are a number of rendering options that might be useful to be exposed to the user. Probably best way to do this is similar to go-spew: have a Config...

Full basic coverage

1

TestBasicTypes should include a field that tests all possible inlined and non-inlined renderers e.g. should have both an `int` field and an `*int` field (and the same for string/uint/etc.) This...

### Expected Behaviour Be able to get nice, simple visualisations as in https://github.com/Arafatk/DataViz ### Actual Behaviour Structures are visualised in full detail, regardless of level of detail needed in the...

Switch to a sane way of generating graphviz files

1

Currently this generates graphviz output directly using string concatenation and formatting. It would be much better to switch to something like https://github.com/gonum/gonum/blob/master/graph/formats/dot

Depth limit

1

### Expected Behavior Be able to limit the depth to which `memviz` maps a structure ### Actual Behavior `memviz` follows pointers arbitrarily far, even if the information I want is...

Map keys need to be sorted to enable deterministic output (and hence snapshot testing of output). This is done by go-spew and the same logic can be copied here.

For maps of the form map[*something]struct{} we can render these specially as a set (i.e. don't bother rendering the empty struct every time). Similar could be done for map[*something]bool but...

Where a map/slice is inline into a struct we should add edge direction hints so that graphviz doesn't try and render the edge starting from inside the struct. See section...

E.g. a different shape for struct vs slice vs map