Peter Kristensen

My fix uses the F key instead of D, don't know the significance thou, google maps api's is a bit strange

Bump, our team just spend hours debugging the access token problem until we found this issue and #61

Seeing this too, It looks like there's not great test coverage of the prometheus exporter

There's a simple test that would have caught this issue: https://github.com/uber-go/tally/compare/master...ptxmac:tally:test-prom I used this with git bisect: > 2498a0dc9e7370c10e54d24ff5ee307845bcea73 is the first bad commit

Found a workaround / correct way to initialize the root scope: ```go tally.NewRootScope(tally.ScopeOptions{ Prefix: "prefix", Tags: map[string]string{"env": "dev"}, CachedReporter: r, Separator: prometheus.DefaultSeparator, SanitizeOptions: &prometheus.DefaultSanitizerOpts, }, 1*time.Second) ``` I guess that...

It looks like this is because the input terminal is always converted to raw, even if the output isn't a terminal / the render is the nil-renderer: https://github.com/charmbracelet/bubbletea/blob/master/tty_unix.go#L19

I tried running the workflow on my own fork, but that failed - unsure if that's a problem with my repo or if the workflows are broken

I think it's because synology still use aufs as the storage driver, and from what I can find setcap isn't supported on aufs: https://github.com/moby/moby/issues/5650

Hmm, that might work, though it doesn't fit well in my current setup to have this built in a different host. For now just setting `XCADDY_SETCAP=0` fixes my immediate problem

> Mess with pointer data via CGO is not that pleasant after all. agreed, but for certain applications the loss of precision when converting between float and double is unacceptable....