Contributing to Golang using Google's Pixelbook

In my previous article I’ve explained how I’ve set up my Google Pixelbook for development in Go. Since tomorrow starts Gophercon UK, I’m in the mood for digging a little deeper, so I decided to make a contribution to the Go language with my new setup.

If you have never contributed to the Go language I strongly suggest you check the guide on this link. I’ll cover some aspects of it over the course of this text, but in case of doubt please go to the source.

The first thing you need before contributing to Go (besides having Go installed) is to sign a CLA, the Contributor Licensing Agreement. I have already signed it, so I’ll skip this step. If you haven’t signed it yet please follow the instructions on this link.

Configuring git

git already comes pre-installed in the Pixelbook’s Linux container, so it’s just a matter of configuring it with my credentials:

$ git config --global user.email [email protected]$ git config --global user.name "Your Name"

Please change [email protected] and Your Nameto reflect the account you used to sign the CLA.

Next step is to configure authentication as described on the contributor’s guide. Basically you have to access https://go.googlesource.com/ and generate a password, which will give will a script to run on the terminal to configure git accordingly.

Finally, you need a Gerritt account, which can be obtained at https://go-review.googlesource.com/login/.

Enough with credentials, let’s get some tools!

Installing the contributor tools

You will need two development tools: go-contrib-init and git-codereview . You can download both with go get :

$ go get -u golang.org/x/tools/cmd/go-contrib-init$ go get -u golang.org/x/review/git-codereview

Both tools will be installed to your $GOPATH which defaults to $HOME/go , so you will need to add ~/go/bin to your PATH environment variable. Edit ~/.profile to make the changes permanent:

# add golang to PATHif [ -d "/usr/local/go/bin" ] ; thenPATH="$PATH:/usr/local/go/bin:~/go/bin"fi

Please note that you need to either source ~/.profile or restart the terminal and/or VS Code for the changes to make effect.

You may test the setup by running git-codereview :

$ git-codereviewUsage: git-codereview <command> [-n] [-v]Type "git-codereview help" for more information.

Next step is to make it available from git review :

$ sudo ln -s ~/go/bin/git-codereview `git --exec-path`

We are creating a symbolic link for `git-codereview` on the git execution path. That will enable you to run git codereview as follows:

$ git codereview help

Cloning the repo

Now let’s give Go’s source tree a new home:

$ mkdir ~/golang$ cd ~/golang$ git clone --depth=1 https://go.googlesource.com/go

You will need to install the gcc binaries on the VM in order to compile Go:

$ sudo apt-get install gcc

Now to be sure everything is ok try compiling the code:

$ cd ~/golang/go/src$ ./all.bash

Please note this may take a long time. My Pixelbook is the i5 version with 8 GB of RAM and it took about 11 minutes.

Also, I was expecting to see the message ALL TESTS PASSED at the end of the build, but got this instead:

##### ../misc/cgo/testcshared--- FAIL: TestUnexportedSymbols (0.64s)cshared_test.go:353: run: [go build -buildmode=c-shared -installsuffix testcshared -o libgo2.so libgo2]cshared_test.go:367: run: [gcc -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build783986620=/tmp/go-build -gno-record-gcc-switches -I pkg/linux_amd64_shared -o testp2 main2.c -Wl,--no-as-needed libgo2.so]cshared_test.go:373: run: [./testp2]cshared_test.go:376: # NAN ChangeLog

**

FAIL2018/07/31 23:09:06 Failed: exit status 1

Since I haven’t changed a single line of code it seems that this test came broken from the original code.

I’ve found a similar issue on GitHub and although it’s not the same problem it gave me a suggestion of the root cause. It seems that inside the Linux VM on the Pixelbook the fd 30 has some special meaning, so I reverted the fix on that issue to fd 100 in both ~/golang/go/misc/cgo/testcshared/src/libgo2/libgo2.go and ~/golang/go/misc/cgo/testcshared/main2.c and the test got back to green:

(...)##### API check

ALL TESTS PASSED---Installed Go for linux/amd64 in /home/danielapetruzalek/golang/goInstalled commands in /home/danielapetruzalek/golang/go/bin*** You need to add /home/danielapetruzalek/golang/go/bin to your PATH.

I’m not planning to commit that change, but I’ve created the issue #26730 with my findings. Let’s put that aside for now and find something to work on.

Finding a contribution

The biggest challenge to contributing to Go, in my humble opinion, is to find a nice issue to work on. If you are like me and don’t have too much experience writing compiler code, I suggest you find a very simple issue to just test the process and progressively increase complexity of the issues over time.

You can find some nice first issues looking for the tag help wanted and/or Documentation . Here’s a link to one of such queries:

https://github.com/golang/go/issues?page=3&q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22

For the purpose of this article I’ve chosen the following issue: https://github.com/golang/go/issues/25082

As it seems the solution has been decided (change the docs), but no one has implemented it yet. Time to get my hands dirty. :)

Let’s create a new branch and initialize the contribution.

$ cd ~/golang/go/src$ git checkout -b "danicat-25082"$ go-init-contrib

Next I’ll edit both files to fix the comments.

$ code fmt/doc.go strconv/ftoa.go

Here’s the diff:

Then it’s time to git add :

$ git add fmt/doc.go strconv/ftoa.go$ git statusOn branch danicat-25082Changes to be committed:(use "git reset HEAD <file>..." to unstage)

    modified:   fmt/doc.go  
    modified:   strconv/ftoa.go

Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)

    modified:   ../misc/cgo/testcshared/main2.c  
    modified:   ../misc/cgo/testcshared/src/libgo2/libgo2.go

Please note that I’m ignoring the hot fix I did to make the build pass as stated above, so I’m only committing doc.go and ftoa.go . I’m following Gerrit’s contribution flow, so I’m committing with git codereview change :

$ git codereview change

And here’s my finished commit:

commit dedfb924340eeef2e3a66ac29aaac8d779eaf7c1Author: Daniela Petruzalek <[email protected]>Date: Wed Aug 1 00:19:55 2018 +0000

strconv: clarify "g" and "G" precision in the docs

Fix the wording in "strconv" and "fmt" to make explicitthat the "g" and "G" formats remove trailing zeroes.

Fixes #25082

Change-Id: I2e2ad0a98d2ea27a3a8a006a0563b366f7a3b71b

Now it’s time to test the build again (just to be sure) and then submit the fix via git codereview mail :

$ ./all.bashBuilding Go cmd/dist using /usr/local/go.Building Go toolchain1 using /usr/local/go.Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.Building Go toolchain2 using go_bootstrap and Go toolchain1.Building Go toolchain3 using go_bootstrap and Go toolchain2.Building packages and commands for linux/amd64.

##### Testing packages.ok archive/tar 0.069sok archive/zip 2.197s(...)

ALL TESTS PASSED---Installed Go for linux/amd64 in /home/danielapetruzalek/golang/goInstalled commands in /home/danielapetruzalek/golang/go/bin*** You need to add /home/danielapetruzalek/golang/go/bin to your PATH.

$ git codereview mailremote: Processing changes: new: 1, doneremote:remote: New Changes:remote: https://go-review.googlesource.com/c/go/+/127135 strconv: clarify "g" and "G" precision in the docsremote:

And we are done! You may follow the link to see how it shows on Gerrit.

Now it’s up to the core team to approve and merge the commit or not, but in regarding to the process, everything that is needed to do a serious code contribution to Go was covered.

UPDATE: Wow, that was quick! And now (5 minutes later) it’s merged \o/

It’s always nice to get a +2 from Rob Pike =)

With this I conclude that indeed the Pixelbook is very capable of replacing my former personal laptop in regards to coding capabilities. VS Code runs smoothly and I haven’t found anything that is a deal-breaker. That weird bug with the file descriptor could have been a thing if I hadn’t created an workaround, but so far I don’t think it will become a bigger issue.