bradleyjkemp / memviz Goto Github PK

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 actually near the top of the graph.

Example input

Support a MaxDepth option like so:
memviz.Config.MaxDepth = 10

I combined memviz with https://github.com/sitano/gsysint to display structure of runtime.g, and there are many fields in this struct.

Expected Behaviour

What were you wanting/expecting to happen?
The layout of a struct can be displayed as multiple lines or a table or something.

Actual Behaviour

What actually happens at the moment?
The struct is displayed as a single line, and too wide.

Example input

If possible, provide a small code sample which reproduces the issue (or, for a feature request, code that should work after the feature is implemented)

package main

import (
	"os"
	"sync/atomic"
	"unsafe"

	"github.com/bradleyjkemp/memviz"
	"github.com/sitano/gsysint"
)

func main() {
	var gp unsafe.Pointer

	atomic.StorePointer(&gp, gsysint.GetG())

	gg := (*gsysint.G)(gp)
	memviz.Map(os.Stdout, gg)
}

Screenshot/Example output (if applicable)

digraph {

}

On the short description; its visualize, not visualise

Enables mapping of structures without a single entry point (i.e. that don't have a root element)

It's been pointed out that memmap already has a conflicting meaning.
Creating this ticket to guage reaction and vote on suggestions.
Should the name be changed? Suggestions welcome.

map[something]struct{} (and similar) fail to render because the { and } are not escaped in the output.
strconv.Quote should be used on all type strings to prevent this.

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 won't test interactions between the different types but at least gives a basic overview of all the different simple types.

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 that's less safe as that might not actually be a set

The "address" of a map reflect.Value is actually the address of the struct field so although maps are reference types they get treated as if they have been copied if two e.g. structs reference the same map.
Not sure we can actually solve this

package main

import (
	"fmt"
	"reflect"
)

type container struct {
	links map[string]string
}

func main() {
	
	test := &container{
		map[string]string{"hello":"world"},
	}
	
	copied := &container{}
	copied.links = test.links
	
        // here UnsafeAddr() (which we use for unique ids) are different
	fmt.Println(reflect.ValueOf(test).Elem().Field(0).UnsafeAddr(), reflect.ValueOf(copied).Elem().Field(0).UnsafeAddr())
}

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 output e.g. can't be used to create a simple diagram of a binary tree without showing all the fields/names/etc.

Currently anonymous structs have a blank name. It would be nice to just have a default name of "[]struct" or something.

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

The readme shows a graphic of a data structure. Does memviz support vizualizing a data structure? If so, are there any examples of how to do this?

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

Child should be given a dedicated cell to put any representation they want in.

Child needs to be given some kind of field id in order to be able to uniquely name cells (e.g. if the same map is referenced by two structure fields).

If a child is inlined then we cannot cache the result (otherwise any links won't be made again). Maybe can but only if it doesn't make any links of its own?

Expected Behaviour

Update readme to reflect - How to use this app? where to install? which languages are supported? If i am not a go user, and still want it, how can that be made possible? A code snipped would do wonders.

Actual Behaviour

The code usage behavior. Actual installation or how to include it is not mentioned?

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.

I'm getting syntax errors when trying to run the output through dot, for example:

axelw@axelw-1 ~/src/github.com/bradleyjkemp/memmap/.snapshots$ dot TestFib 
Error: TestFib: syntax error in line 1 near '('

I assume I don't have a sufficiently recent version of graphviz installed, this is dot -version:

dot - graphviz version 2.38.0 (20140413.2041)
libdir = "/usr/lib/graphviz"
Activated plugin library: libgvplugin_dot_layout.so.6
Using layout: dot:dot_layout
Activated plugin library: libgvplugin_core.so.6
Using render: dot:core
Using device: dot:dot:core
The plugin configuration file:
	/usr/lib/graphviz/config6a
		was successfully loaded.
    render	:  cairo dot fig gd map pic pov ps svg tk vml vrml xdot
    layout	:  circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
    textlayout	:  textlayout
    device	:  canon cmap cmapx cmapx_np dot eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg pdf pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz vrml wbmp x11 xdot xdot1.2 xdot1.4 xlib
    loadimage	:  (lib) eps gd gd2 gif jpe jpeg jpg png ps svg xbm

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 3.1 in http://www.graphviz.org/pdf/dotguide.pdf

I'm forgoing your issue template since it's format is orthogonal to the issue at hand.

The latest tagged release (v0.2.2) is from 25 Jan 2018 -- back when the package was still named memmap. This is what gets downloaded by go get when using a modern (i.e. module-aware) version of Go.

Therefore, if I import "github.com/bradleyjkemp/memviz" into a project that uses modules, I'm compelled to reference it as package memmap... and this acutely unballances my already precarious feng shui.

Please tag a new release where the package name and the repo's basename agree.

Thankyouverymuchandhaveaniceday.

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 struct which has the Map function and then a global default options struct which is used by the package level Map function.