dave.cheney.netDave Cheney | The acme of foolishness

Dave Cheney The acme of foolishness Menu High Performance Go Practical Go Internets of Interest About RSS Microblog: TestMain can cause one to question reality This morning a one line change had several of us tearing up the fabric of reality trying to understand why a failing test wasn’t failing, or, in fact, being run at all. Increasingly frantic efforts toYou can see it clearly, y ends up being zero so the program crashes. To write a test, you need to get the conditions that caused y to be zero to occur on command. There are only two parameters passed into this function, this shouldn’t be hard. Oh, but this is a method, not a function, so you need to construct an instance of the object in the right state to trigger the bug. Hmm, this language uses constructors to make sure people can’t just monkey up the bits of the object they need for a test, you’ll have to find, mock, stub or build instances of all the objects dependencies (and their dependencies, and so on) then run the object through the precise series of operations to put the it in the state that causes y to be empty. Then you can write the test. At this point Tuesday night drinks are fading before you eyes. Without being able to write a test for your fix, how will you convince a reviewer that it actually fixed what it fixed? All you can prove was your simple” change didn’t break any behaviour that was covered by existing tests. Fast forward to Friday and your one line change has finally been merged, along with a few new test cases to make sure it doesn’t happen again. Next week you’re going to sit down and try to figure out a bunch of weird crashes you caused while trying to stub out calls to the database. Eventually you gave up and copied some code from another test that uses a copy of production data. It’s much slower than it needs to be, but it worked, and was the only way to put a reasonable estimate on a job that had already consumed your entire week. The moral of the story; was the test the reason it took nearly a week to make a one line fix? This entry was posted in Programming , Small ideas on December 15, 2020 by Dave Cheney . How to dump the GOSSAFUNC graph for a method The Go compiler’s SSA backend contains a facility to produce HTML debugging output of the compilation phases. This post covers how to print the SSA output for function and methods. Let’s start with a sample program which contains a function, a value method, and a pointer method: package main import ( "fmt" ) type Numbers struct { vals []int } func (n *Numbers) Add(v int) { n.vals = append(n.vals, v) } func (n Numbers) Average() float64 { sum := 0.0 for _, num := range n.vals { sum += float64(num) } return sum / float64(len(n.vals)) } func main() { var numbers Numbers numbers.Add(200) numbers.Add(43) numbers.Add(-6) fmt.Println(numbers.Average()) } Control of the SSA debugging output is via the GOSSAFUNC environment variable. This variable takes the name of the function to dump. This is not the functions fully qualified name. For func main above the name of the function is main not main.main . % env GOSSAFUNC=main go build runtime dumped SSA to ../../go/src/runtime/ssa.html t dumped SSA to ./ssa.html In this example GOSSAFUNC=main matched both main.main and a function called runtime.main . 1 This is a little unfortunate, but in practice probably not a big deal as, if you’re performance tuning your code, it won’t be in a giant spaghetti blob in func main . What is more likely is your code will be in a method , so you’ve probably landed on this post looking for the correct incantation to dump the SSA output for a method. To print the SSA debug for the pointer method func (n *Numbers) Add , the equivalent function name is (*Numbers).Add : 2 % env "GOSSAFUNC=(*Numbers).Add" go build t dumped SSA to ./ssa.html To print the SSA debug for a value method func (n Numbers) Average , the equivalent function name is (*Numbers).Average even though this is a value method : % env "GOSSAFUNC=(*Numbers).Average" go build t dumped SSA to ./ssa.html This entry was posted in Go , Programming and tagged compiler , gossafunc , ssa on June 19, 2020 by Dave Cheney . Diamond interface composition in Go 1.14 Per the overlapping interfaces proposal , Go 1.14 now permits embedding of interfaces with overlapping method sets. This is a brief post explain what this change means: Let’s start with the definition of the three key interfaces from the io package; io.Reader , io.Writer , and io.Closer : package io type Reader interface { Read([]byte) (int, error) } type Writer interface { Write([]byte) (int, error) } type Closer interface { Close() error } Just as embedding a type inside a struct allows the embedded type’s fields and methods to be accessed as if it were declared on the embedding type 1 , the process is true for interfaces. Thus there is no difference between explicitly declaring type ReadCloser interface { Read([]byte) (int, error) Close() error } and using embedding to compose the interface type ReadCloser interface { Reader Closer } You can even mix and match type WriteCloser interface { Write([]byte) (int, error) Closer } However, prior to Go 1.14, if you continued to compose interface declarations in this manner you would likely find that something like this, type ReadWriteCloser interface { ReadCloser WriterCloser } would fail to compile % go build interfaces.go command-line-arguments ./interfaces.go:27:2: duplicate method Close Fortunately, with Go 1.14 this is no longer a limitation, thus solving problems that typically occur with diamond-shaped embedding graphs. However, there is a catch that I ran into attempting to demonstrate this feature to the local user group–this feature is only enabled when the Go compiler uses the 1.14 (or later) spec. As near as I can make out the rules for which version of the Go spec is used during compilation appear to be: If your source code is stored inside GOPATH (or you have disabled modules with GO111MODULE=off ) then the version of the Go spec used to compile with matches the version of the compiler you are using. Said another way, if you have Go 1.13 installed, your Go version is 1.13. If you have Go 1.14 installed, your version is 1.14. No surprises here. If your source code is stored outside GOPATH (or you have forced modules on with GO111MODULE=on ) then the go tool will take the Go version from the go.mod file. If there is no Go version listed in go.mod then the version of the spec will be the version of Go installed. This is identical to point 1. If you are in module mode, either by being outside GOPATH or with GO111MODULE=on , but there is no go.mod file in the current, or any parent, directory then the version of the Go spec used to compile your code defaults to Go 1.13. The last point caught me out. This entry was posted in Go , Programming and tagged compiler , interfaces on May 24, 2020 by Dave Cheney . Fatih’s question A few days ago Fatih posted this question on twitter. I’m going to attempt to give my answer, however to do that I need to apply some simplifications as my previous attempts to answer it involved a lot of phrases like a pointer to a pointer , and other unhelpful waffling. Hopefully my simplified answer can be useful in building a mental framework to answer Fatih’s original question. Restating the question Fatih’s original tweet showed four different variations of json.Unmarshal . I’m going to focus on the last two, which I’ll rewrite a little: package main import ( "encoding/json" "fmt" ) type Result struct { Foo string `json:"foo"` } func main() { content := []byte(`{"foo": "bar"}`) var result1, result2 *Result err := json.Unmarshal(content, &result1) fmt.Println(result1, err) // &{bar} nil err = json.Unmarshal(content, result2) fmt.Println(result2, err) // nil json: Unmarshal(nil *main.Result) } Restated in words, result1 and result2 are the same type; *Result . Decoding into result1 works as expected, whereas decoding into result2 causes the json package to...