profile
viewpoint
Caleb Spare cespare Liftoff Palo Alto, CA I make Go servers fast at @liftoffio.

created tagcespare/markdownd

tagv0.2.0

A markdown renderer and server for your command line.

created time in 10 hours

push eventcespare/markdownd

Caleb Spare

commit sha 6e3289253ffddce09e96f3b5df6186313db0678a

Update go.mod

view details

push time in 10 hours

push eventcespare/dotfiles

Caleb Spare

commit sha 310805790cf1fbdbe29698e26dbe5be1110fc552

Tweak terminal background color

view details

push time in 4 days

created tagliftoffio/dominikh-go-tools

tag2019.2.3-liftoff1

Staticcheck – a collection of static analysis tools for working with Go code

created time in 4 days

delete tag liftoffio/dominikh-go-tools

delete tag : 2019.2.3-liftoff1

delete time in 4 days

push eventliftoffio/dominikh-go-tools

Caleb Spare

commit sha 4827b20d15d10a2e91129bef39f303aac533067b

Update version

view details

push time in 4 days

created tagliftoffio/dominikh-go-tools

tag2019.2.3-liftoff1

Staticcheck – a collection of static analysis tools for working with Go code

created time in 4 days

create barnchliftoffio/dominikh-go-tools

branch : liftoff

created branch time in 4 days

created tagliftoffio/dominikh-go-tools

tag2019.2.3-liftoff0

Staticcheck – a collection of static analysis tools for working with Go code

created time in 5 days

issue commentdominikh/go-tools

staticcheck: flag uses of log.Fatal inside tests (should be t.Fatal)

I just looked for these in our codebase and it was way more common than I expected. (I used the simple heuristic of searching for the string log.Fatal in *_test.go files and examining each manually.)

I found:

  • 84% of log.Fatals should have been t.Fatal. The main cases where it was intended was in init or TestMain.
  • A mistaken log.Fatal appeared about once every 4000 lines of test code.
cespare

comment created time in 5 days

issue openeddominikh/go-tools

SA1015: false positive due to faulty exit analysis

73512b738d093c5dfdacc7a6bea7e17b1c26e741 introduced a bug that causes a false positive in SA1015.

// Package scfp demonstrates staticcheck false positives.
package scfp

import (
	"fmt"
	"sync/atomic"
	"time"
)

func Foo() {
	if atomic.SwapUint32(&called, 1) != 0 {
		panic("called more than once")
	}
	for range time.Tick(10 * time.Second) {
		fmt.Println("HI")
	}
}

var called uint32
exp/scfp/scfp.go:14:12: using time.Tick leaks the underlying ticker, consider using it only in endless functions, tests and the main package, and use time.NewTicker here (SA1015)

Foo is an endless function, but staticcheck seems to have not realized that due to the panic above.

created time in 5 days

issue openeddominikh/go-tools

unused: faulty exit path analysis causes false positives for U1000, SA4006

ee025456fe28d312734efa477be2a8ecd13f04fe introduced a bug whereby certain values and functions in test code are mistakenly marked as unused. Here's a repro that triggers both U1000 and SA4006:

package scfp

import (
	"os"
	"testing"
)

var m = map[string]*int{"A": new(int)}

func TestUnused1(t *testing.T) {
	p := m["A"]
	xxx(t)

	foo(*p)
}

func xxx(t *testing.T) {
	err := a()
	if err != nil {
		os.Exit(1)
	}
	err = b()
	if err != nil {
		t.Fatal(err)
	}
}

func foo(n int) {}

func a() error {
	return nil
}

func b() error {
	return nil
}
exp/scfp/scfp_test.go:11:2: this value of p is never used (SA4006)
exp/scfp/scfp_test.go:28:6: func foo is unused (U1000)

The interesting thing happening here is that the test helper calls both os.Exit and t.Fatal. It seems to not trigger without both of these. I didn't dig in further, though.

(Separately, I believe that all the cases that trigger this false positive have a log.Fatal somewhere in the test setup code that ought to be a t.Fatal. See #649.)

created time in 5 days

issue openeddominikh/go-tools

staticcheck: flag uses of log.Fatal inside tests (should be t.Fatal)

A mistake I see and make with some regularity is accidentally using log.Fatal{,f,ln} rather than the appropriate t.Fatal method. Would you consider flagging these?

Some questions to answer first:

  • Which methods should be flagged? log.Fatal and log.Fatalf are the clearest, since they have matching methods on testing.T. What about log.Fatalln? Should log.PrintX methods be t.LogX instead?
    • I think my vote would be to flag log.Fatal, log.Fatalf, and log.Fatalln only.
  • In what functions should we look for these calls? The simplest would be directly inside TestXxx functions in test files, but that would miss test helpers. Ideally we would even catch test helpers that live in other (non-test) packages. Perhaps the heuristic should be any context in which any testing.TB is in scope at all. Here's a tricky example:
    type testFoo struct {
    	t testing.TB
    	/* ... */
    }
    
    func (f *testFoo) check() {
    	if blah() {
    		log.Fatal("blah") // should be f.t.Fatal("blah")
    	}
    }
    

created time in 5 days

issue commentdominikh/go-tools

U1000 error for unused functions which are used in skipped test

(but that is very clever analysis!)

leslie-qiwa

comment created time in 5 days

issue commentdominikh/go-tools

U1000 error for unused functions which are used in skipped test

This flags a couple of things in our repo too.

leslie-qiwa

comment created time in 5 days

push eventcespare/go-tools

Dominik Honnef

commit sha a9480a3ec3bcedcf32d00a67bb464c058ba03281

unused: fix racy node creation The 'node' function non-atomically loaded an existing node or created a new one. This could lead to two goroutines each creating new nodes. This would ultimately lead to false positives when checking a package and its test variant, because objects wouldn't be deduplicated correctly. Instead of using LoadOrStore, we switch away from sync.Map completely and use coarse locking on normal maps. Using LoadOrStore would require us to allocate nodes just to throw them away afterwards, at a high rate. At the same time, using normal maps + a mutex does not have a measurable performance impact – as determined by benchmarking against the standard library. We also remove the context-local typeNodes map. It served as a lock-free fast path, but benchmarking shows that it has no measurable performance impact, either. Thanks to Caleb Spare for uncovering this fairly embarrassing blunder. Closes gh-642

view details

push time in 5 days

issue commentgolang/go

cmd/go: doc fails on case-insensitive search for identifier similar to keyword

This bites me semi-regularly. I never type capital letters into my go doc query (why bother?) and so I get annoying failures every time the thing I'm looking for happens to be a keyword.

$ go doc sort.interface
doc: invalid identifier "interface"
exit status 1
$ go doc types.type
doc: invalid identifier "type"
exit status 1
DeedleFake

comment created time in 6 days

issue commentdominikh/go-tools

staticcheck: rare false positive in U1000

Took me way too long to figure out, but I understand this bug now.

First, here's a fairly reliable repro:

https://github.com/cespare/go-tools/commit/356eff04f38552e30aa1f53d1885e8bd0be8a1a9

(After checking that out, you can follow the directions in the commit message.)

The problem is that the objNodes sync.Map in unused is accessed in a racy way here:

https://github.com/dominikh/go-tools/blob/f51cd49dbadb98d60043a445a177e72f0cc62e6b/unused/unused.go#L870-L885

The problem happens something like this (assuming we have mypkg with a function xxx that is used only in the test):

  • Though we're running on a single package, packages.Load gives us 3 packages: the package under test, the testing variant of the package (including test files), and the synthetic testing mypkg.test package. (That last one doesn't matter for our purposes.)
  • The two variants of the package under test are inserted into the unused graph in parallel.
  • When we find the (*types.Func) for xxx (in both packages), it could so happen that we enter (*Graph).node for both packages at the same time.
  • The goroutines race on the load and subsequent store of g.objNodes. That is, they construct the same key, both goroutines load nothing, and then both goroutines store a new node. Both nodes end up in g.Nodes.
  • Now depending on which goroutine lost the store race, one of the duplicate funcs in the graph will appear unused.

In fact, in my testing I found that it's fairly common to have duplicate values in the graph that should have been deduplicated. Most of the time this doesn't trigger a false positive since the value will be used in both packages that raced to add it to the graph. It requires the somewhat unusual condition of having an unexported function in one package that is only used in the testing package.

cespare

comment created time in 6 days

create barnchcespare/go-tools

branch : u1000-repro

created branch time in 6 days

push eventcespare/go-tools

Caleb Spare

commit sha 49f0c96888a7ef3a63107996d2dee09cf676e753

More debug

view details

push time in 6 days

push eventcespare/go-tools

Caleb Spare

commit sha 585affe79998299bd382e3f5d1fc8cb3ed5a32d1

More debug prints

view details

push time in 6 days

push eventcespare/go-tools

Caleb Spare

commit sha 50cf82353be89d537f15a4d20a81ab79407bb5bf

More debug

view details

push time in 6 days

push eventcespare/go-tools

Caleb Spare

commit sha d2d0f2a8af8c1f60b2fc5c26cacbe246b79ee339

Add debug prints

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha 8afb60c9f6d2b5e53626a0e734730ac0a2aaf0ea

More debug

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha eadf8619589d676c3b73cbcf47940874f6b8e935

More debug

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha 2ba2927323b223daa31f30424968ca78c9d512dd

More debug

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha 67cba29c5ae2ce52f6a23a1f943e5f7451fc232b

More debug

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha 9c9222b67767baf95b42c468d583f7a9d60a0fa1

Insert sleeps

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha 2ec01d7bb1e6ffe9850b70cd62fdf8bb464126d6

Add some unused funcs to pattern

view details

push time in 7 days

push eventcespare/go-tools

Caleb Spare

commit sha dadb77f9ba24c29bade5c7937d910bdbacfb34d8

Add some unused funcs to pattern

view details

push time in 7 days

create barnchcespare/go-tools

branch : u1000-debug

created branch time in 7 days

issue commentdominikh/go-tools

staticcheck: rare false positive in U1000

Status update:

I've been able to reproduce within a few minutes by running a whole bunch of staticchecks in parallel. I was able to narrow it down a bit to a failing invocation like staticcheck -checks U1000 one/particular/package. If I run that with GOMAXPROCS=8 or so, it seems to fail after a few hundred runs on average.

For all these tests, each run of staticcheck has its own fresh XDG_CACHE_HOME, GOCACHE, and TMPDIR, so AFAIK there's no shared on-disk state in play.

In addition to 2019.2.3, I've reproduced this at master (f51cd49dbadb98d60043a445a177e72f0cc62e6b).

I've also reproduced this with staticcheck built with -race. There were no race warnings printed out, and it seemed to take longer to repro (not just wall time, but iterations -- I had to run about 3000 before I got a failure).

I've tried reproducing this with a minimal synthetic package but I couldn't get any failures after about 100k runs.

cespare

comment created time in 7 days

issue commentdominikh/go-tools

staticcheck: rare false positive in U1000

@viswajithiii that's an interesting point. It's true that the non-test package, considered in isolation, does have a genuinely unused function/var.

@dominikh can you confirm the intended behavior?

cespare

comment created time in 7 days

fork cespare/go-tools

Staticcheck – a collection of static analysis tools for working with Go code

https://staticcheck.io

fork in 7 days

push eventcespare/misc

Caleb Spare

commit sha 5ca1c5fbdc9f68e7e8bdace1b859fd71f3caa888

Use an example with a solution

view details

push time in 7 days

push eventcespare/misc

Caleb Spare

commit sha 0b1e956aff29ecf72353b9be315024fb0327dfec

Add d2symbols

view details

push time in 8 days

push eventcespare/misc

Caleb Spare

commit sha b886b44fc1bfa1ca6682f398f468664a9d9fbef6

Test gitattributes

view details

push time in 8 days

issue commentgolang/go

blog: unintuitive code in errors post example

FWIW this surprised me at first too.

I had to think about it for a bit to realize why it makes sense this way. (My rough reasoning is something like: we already have a *QueryError, so declaring var e *QueryError and then changing e to the existing *QueryError is analogous to the type assertion. Plus, this way we don't make a copy of the underlying value.)

I think the reason it feels weird at first is that the code looks similar to a common pattern used in JSON unmarshaling and similar contexts, where you might well do (supposing the QueryError could unmarshal itself from JSON):

var e QueryError
if err := json.Unmarshal(b, &e); err != nil { ... }

In that case, there was no QueryError to begin with, so we need to create one and fill it in; in the errors.As context, we already have the value and we just need to get the pointer to it again.

kevinburkemeter

comment created time in 8 days

issue commentdominikh/go-tools

staticcheck: rare false positive in U1000

I have 384 CPUs working on this.

cespare

comment created time in 8 days

issue openeddominikh/go-tools

staticcheck: rare false positive in U1000

I'm in the process of tracking down what I believe to be a rare, non-deterministic false positive in staticcheck. Unfortunately, this is an issue we've only seen in our CI system running on private code; I've been unable to reliably reproduce it so far.

This is the current version we're using:

$ staticcheck -debug.version
staticcheck 2019.2.3

Compiled with Go version: go1.13
Main module:
        honnef.co/go/tools@v0.0.1-2019.2.3 (sum: h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM=)
Dependencies:
        github.com/BurntSushi/toml@v0.3.1 (sum: h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=)
        golang.org/x/tools@v0.0.0-20190621195816-6e04913cbbac (sum: h1:MQEvx39qSf8vyrx3XRaOe+j1UDIzKwkYOVObRgGPVqI=)

We've seen this false positive occur with Go 1.13.4 and previously with Go 1.12.4.

We also previously saw the false positives with staticcheck 2019.2 and 2019.2.2, but not 2019.1.1 AFAICT.

We're running staticcheck as

staticcheck root/...

(That is, a package selection expression that includes all our Go packages.)

Our CI environment is running on linux/amd64.


Some things I noticed when I browsed the set of false positives:

We've seen 16 false positives in the ~4 months since we upgraded from staticcheck 2019.1.1 to 2019.2. During that time we've had tens or hundreds of thousands of runs in CI (don't have exact numbers available).

All these false positives share a common feature: they flag an unexported name which is defined in a non-test file and is referred to exactly once, in a test file. For example, 6/16 of the false positives were for a particular method similar to this:

// server.go
type server struct {...}
func (s *server) close() { ... }

// server_test.go
func TestXYZ(t *testing.T) {
	s := newTestServer(...)
	defer s.close() // only time s.close is used anywhere

	// ...
}

We have examples with methods, plain functions, and also vars.

I'm working to try to reproduce this, but perhaps this is enough of a clue to give you a lead.

created time in 8 days

issue commentgolang/go

proposal: Go 2: negative slice/array indexes

@ianlancetaylor to me, that seems an argument in favor of @bcmills's _ proposal.

lastRepeat[:_-len(after)]
pjebs

comment created time in 8 days

push eventcespare/dotfiles

Caleb Spare

commit sha 206ea00ec8f23c2771a54762047dba0adf4efca9

More terminal tweaking

view details

push time in 11 days

push eventcespare/dotfiles

Caleb Spare

commit sha afc5a5866f18e31bcb8c04d46d3273eeb1c8c0cb

Tweak colors some more

view details

push time in 12 days

push eventcespare/vim-config

Caleb Spare

commit sha 6d0a22464baf749de62b0d73f45ffea4b4031194

Wrap at 80

view details

Caleb Spare

commit sha aea01514e817a7fc2f37e03e742e51a2f24d7986

Improve JSON syntax

view details

push time in 12 days

PR merged cespare/xxhash

Fix minimal go version (>=1.11)

When downloading your library with go <1.13, it fails because of the requirement set in the go.mod file.

+1 -1

4 comments

1 changed file

jooola

pr closed time in 12 days

push eventcespare/xxhash

Jonas L

commit sha b06934cfcfd47f49592e8296621c0abeda88839c

Fix minimal go version (>1.11) When downloading your library with go <1.13, it fails because of the requirement set in the go.mod file.

view details

Caleb Spare

commit sha 2372543dd2bbab7a55ce14c54eb357abe23a42f5

Merge remote-tracking branch 'jooola/patch-1'

view details

push time in 12 days

pull request commentcespare/xxhash

Fix minimal go version (>=1.11)

Ah, I see. This is essentially a bug in Go 1.11, then -- if you're using Go 1.11 for something, you should at least upgrade to Go 1.11.4, which has the bug fix.

Thinking about this more, though, I think it's reasonable to set the language version directive to 1.11 for now, since xxhash isn't using any particularly new features. Then we wouldn't be able to accidentally start using new language features without explicitly bumping the version, which seems good.

jooola

comment created time in 12 days

push eventcespare/xxhash

Caleb Spare

commit sha 34bb48f01fcee1ff49ed3002909415bf0aee859d

Be more specific about supported Go versions

view details

push time in 12 days

pull request commentcespare/xxhash

Fix minimal go version (>=1.11)

The go directive doesn't mean that the module can't be built with earlier versions of go. It controls what language features are available within the module. I don't think xxhash is using any post-Go.11 features, and indeed, it works fine with Go 1.11.4 for me:

$ mkdir /tmp/test111 && cd /tmp/test111 && echo module github.com/blah > go.mod && GO111MODULE=on go1.11.4 test github.com/cespare/xxhash/v2
ok      github.com/cespare/xxhash/v2    0.004s

What command were you running? What version of Go are you using?

jooola

comment created time in 13 days

push eventcespare/vim-config

Caleb Spare

commit sha 2a34304d3cc95a8af336a28450495784fd7e8859

Add vim-eunuch

view details

Caleb Spare

commit sha 979b2e3aea6fa1f4a798203bf9d7d6f941af56db

Upgrade govim

view details

push time in 13 days

push eventcespare/dotfiles

Caleb Spare

commit sha a02c39f33b530b3e85a07abe9099440d66be9ebf

Improve shortcut for nested tmux

view details

push time in 13 days

push eventcespare/dotfiles

Caleb Spare

commit sha 724c0f3757339b9cd71554783d3f23c0cb7839e2

Tweak terminal colors more

view details

push time in 13 days

push eventcespare/vim-config

Caleb Spare

commit sha 189c92cf7b28c42a9ec8378a8bebdf2e5c7f4970

Switch from ag to ripgrep

view details

push time in 13 days

push eventcespare/dotfiles

Caleb Spare

commit sha 8333a3ab81a88405e11951c96400e13b0456acf8

Add ripgrep config

view details

Caleb Spare

commit sha 5967c0f7073e02303f175fe4208797a64cd8f1e8

Adjust terminal colors

view details

push time in 14 days

issue commentgolang/go

cmd/go: flags to control changes to go.mod, go.sum

It is overfitting to a handful of use cases

From my perspective, -g restores the main purpose for which I use go get, previously removed as part of the migration to modules.

Installing tools globally is not a niche use case. See previous comments here and here.

jayconrod

comment created time in 15 days

issue commentgolang/go

Document how using a specific branch of a repo with go modules interacts with multi-module repos

We used to use / for namespacing Git branches at my company, so I guess that's an existence proof that there are indeed repositories containing Go code that have branches with slashes.

That said, this turned out to be a bad idea. Git makes a file for each branch (in .git/refs/heads); if you use slashes in the name, git constructs nested directories. This means that you cannot have two different branches newfeature and newfeature/sub-thing because the directories collide. With a different namespacing character, this isn't a problem.

We switched from / to . a couple of years ago and that has worked well for us.

grantwwu

comment created time in 15 days

issue commentgolang/go

testing: document best practices for avoiding compiler optimizations in benchmarks

I started one of the other discussions about this a few years ago on golang-dev. I think the situation is still quite unfortunate. To the best of my knowledge, I think that situation is:

  1. Examples where the compiler breaks benchmarks (as my code above) are fairly rare in the real world today.
  2. There are a variety of approaches for mitigating this hypothetical problem which have entered the lore, some of which could be themselves thwarted by a sufficiently clever compiler.
  3. If certain optimizations appeared in the gc compiler, they would probably break loads of benchmarks that already exist. (If Go could inline functions with for loops (#14768), which is an important optimization that hasn't been implemented yet, then I expect this issue would suddenly apply to a whole lot more functions out there.)

Given (1) and (2), I think a lot of the current "sink" approaches are not good since they make the code uglier and they are hard to justify (they protect the benchmark against some, but not all, hypothetical future optimizations).

More recently some people have suggested that using runtime.KeepAlive to mark values that you want to always be computed in the benchmark is the best approach (such as @randall77's comment here). That seems better, but is still not completely ideal in two ways:

  • KeepAlive might not convey the meaning as well as something that is named/documented specifically for this purpose. (@randall77 suggested adding a testing.B method which can just delegate to runtime.KeepAlive.)
  • KeepAlive adds a little overhead that seems unnecessary (#33442).

Some comments in these discussions have seemed to suggest that writing microbenchmarks is an advanced task for experienced programmers which always requires some knowledge about the compiler and system underneath and therefore there's nothing to be done here. I don't really buy that, though: I think that even beginners can reasonably want to write benchmarks which measure how long their function f takes to run and compare different approaches to writing f, and we should make it as easy as possible to avoid any future pitfalls where the obvious benchmark code becomes broken.

I advocate that we decide on a single best approach here (which seems to be using runtime.KeepAlive or else a new helper in the testing package), document it thoroughly, and adopt it as widely as possible.

nicksnyder

comment created time in 18 days

issue commentgolang/go

testing: document best practices for avoiding compiler optimizations in benchmarks

Here's an example that demonstrates the problem. You have to be careful to ensure that the function is inlined but also that the result cannot computed at compile time.

package main

import (
	"runtime"
	"testing"
	"time"
)

func BenchmarkX(b *testing.B) {
	for i := 0; i < b.N; i++ {
		f()
	}
}

var sink int

func BenchmarkXSink(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sink = f()
	}
}

func BenchmarkXKeepAlive(b *testing.B) {
	for i := 0; i < b.N; i++ {
		runtime.KeepAlive(f())
	}
}

var input float64

func init() {
	if time.Now().Year() > 1900 {
		input = 123412341234123
	}
}

func f() int {
	x := input
	x /= 7.3
	x /= 7.3
	x /= 7.3
	x /= 7.3
	return int(x)
}

Here's what I get using gc (tip) and gccgo (8.3.0):

$ go test -bench . bench_test.go
goos: linux
goarch: amd64
BenchmarkX-4                    1000000000               0.281 ns/op
BenchmarkXSink-4                43315279                24.5 ns/op
BenchmarkXSinkExported-4        49105191                24.5 ns/op
BenchmarkXKeepAlive-4           48882840                24.3 ns/op
PASS
ok      command-line-arguments  5.823s
$ go test -compiler gccgo -bench . bench_test.go
goos: linux
goarch: amd64
BenchmarkX-4                    50000000                24.4 ns/op
BenchmarkXSink-4                50000000                24.4 ns/op
BenchmarkXSinkExported-4        50000000                24.5 ns/op
BenchmarkXKeepAlive-4           20000000                68.6 ns/op
PASS
ok      command-line-arguments  5.286s
nicksnyder

comment created time in 18 days

issue commentgolang/go

cmd/go: flags to control changes to go.mod, go.sum

Somewhat tangential, but I don't think -g=main is a good idea for a flag. Like normal flags flags, the flag should either be boolean or not boolean. Otherwise -g main won't work as expected. (Discussed recently in the context of go test -shuffle over at https://github.com/golang/go/issues/28592#issuecomment-538059551.)

jayconrod

comment created time in 19 days

issue commentcespare/xxhash

cespare/xxhash/v2 was deleted

As I mentioned in #31, you need a version of Go with module support (1.11+) to use v2 of this module.

udayangaac

comment created time in 19 days

issue commentcespare/xxhash

missing v2 visibility

You definitely need a version of Go with module support (1.11+) to use v2 of this module.

I added a note to the README in 997e1685cae39ce5a9573990e7fabe3e796898a0.

wfbrown53

comment created time in 19 days

push eventcespare/xxhash

Caleb Spare

commit sha 997e1685cae39ce5a9573990e7fabe3e796898a0

Add note about using Go 1.11+

view details

push time in 19 days

issue commentgolang/go

testing: 'go test' broken in go1.13

@gbbr the reason we considered this an acceptable change is that calling flags.Parse in an init was always arguably incorrect. There might be other packages that have not yet registered their flags at that point.

I suggest you modify your code to avoid calling flags.Parse inside init.

gbbr

comment created time in 20 days

issue commentgoogle/wire

wire: test flakes on Travis with "failed to cache compiled Go files"

@zombiezen the Go bug was fixed for Go 1.13. This shouldn't be happening anymore. (I checked that the repro no longer fails.)

zombiezen

comment created time in 25 days

issue commentgolang/go

cmd/vet: false positives with new fmt verbs %x/%X for floating-point and complex numbers

I believe the fix is trivial. I'll send a CL for x/tools and then re-vendor the copy in src/cmd after that's merged.

cespare

comment created time in 25 days

issue openedgolang/go

cmd/vet: false positives with new fmt verbs %x/%X for floating-point and complex numbers

I don't think vet has been updated for the new %x and %X verbs for floating-point and complex numbers.

I checked with Go 1.13 and tip. Here's a demo:

https://play.golang.org/p/-cexq-umzUo

Code:

package main

import "fmt"

func main() {
	fmt.Printf("%x\n", 1.234)
	fmt.Printf("%x\n", 1.2+3i)
	fmt.Printf("%X\n", 1.234)
	fmt.Printf("%X\n", 1.2+3i)
}

Output:

./prog.go:6:2: Printf format %x has arg 1.234 of wrong type float64
./prog.go:7:2: Printf format %x has arg 1.2 + 3i of wrong type complex128
./prog.go:8:2: Printf format %X has arg 1.234 of wrong type float64
./prog.go:9:2: Printf format %X has arg 1.2 + 3i of wrong type complex128
Go vet exited.

0x1.3be76c8b43958p+00
(0x1.3333333333333p+00+0x1.8p+01i)
0X1.3BE76C8B43958P+00
(0X1.3333333333333P+00+0X1.8P+01i)

Program exited.

created time in a month

issue commentcespare/xxhash

missing v2 visibility

FWIW if I clone https://github.com/carlpett/stream_exporter I can run govendor build +p and it works.

wfbrown53

comment created time in a month

issue commentcespare/xxhash

missing v2 visibility

You haven't given me an indication that there's a problem with my module. You can see for yourself that the git tag is there. If there's a problem with govendor, take it up with @kardianos.

wfbrown53

comment created time in a month

issue commentcespare/xxhash

missing v2 visibility

Yes: https://github.com/cespare/xxhash/tree/v2.1.0

I don't know what the problem is, but I don't think it's on my end.

$ git clone https://github.com/prometheus/client_golang /tmp/prom
Cloning into '/tmp/prom'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 4808 (delta 1), reused 1 (delta 0), pack-reused 4802
Receiving objects: 100% (4808/4808), 1.64 MiB | 5.72 MiB/s, done.
Resolving deltas: 100% (2950/2950), done.
$ cd /tmp/prom/prometheus
$ go test -run xxx
testing: warning: no tests to run
PASS
ok      github.com/prometheus/client_golang/prometheus  0.004s
$ go mod graph | grep xxhash
github.com/prometheus/client_golang github.com/cespare/xxhash/v2@v2.1.0

The fact that #31 was filed yesterday makes me wonder what's happening, though.

wfbrown53

comment created time in a month

issue closedcespare/xxhash

missing v2 visibility

Trying to build a govendor package and the github.com/prometheus/client_golang references a xxhash/v2, specically github.com/cespare/xxhash/v2 v2.1.0. Is that version available for build purposes?

closed time in a month

wfbrown53

issue closedcespare/xxhash

cespare/xxhash/v2 was deleted

@cespare we faced such error when building our project using glide [ERROR] Error scanning github.com/cespare/xxhash/v2: cannot find package "." in: /home/chamith/.glide/cache/src/https-github.com-cespare-xxhash/v2

closed time in a month

udayangaac

issue commentcespare/xxhash

cespare/xxhash/v2 was deleted

I haven't changed anything. This sounds like a problem you're having with Glide.

udayangaac

comment created time in a month

issue commentgolang/go

proposal: runtime: add a mechanism for specifying a minimum target heap size

@aclements bump on the questions I asked in https://github.com/golang/go/issues/23044#issuecomment-517037631.

cespare

comment created time in a month

pull request commentcespare/subcmd

Support nested sub-commands

Thanks!

rayjcwu

comment created time in a month

PR merged cespare/subcmd

Support nested sub-commands

The API became

cmds := []subcmd.Commend{
  { Name: "foo", Do: foo },
}

fooCmds := []subcmd.Command{
  { Name: "foobar", Do: foobar },
  { Name: "footage", Do: footage },
}

func main() {
  subcmd.Run(cmds)
}

func foo(args []string) {
  // Dispatch to different cmds based on args[0]
  subcmd.NewFlagSet("sub", cmds).Run(args)  
}

func foobar(args []string) {
  fs := flag.NewFlagSet("....")
  fs.Parse(args)
  ...
}

In order for Usage to print out parsed arguments, args need to be a tailing subslice (args = os.Args[i:] for some i) of os.Args.

+130 -38

5 comments

3 changed files

rayjcwu

pr closed time in a month

push eventcespare/subcmd

Ray Wu

commit sha c5038215eb9ee230cf645d47a99907dac95c45a3

Support nested sub-commands

view details

push time in a month

created tagcespare/subcmd

tagv1.1.0

A minimal Go package for CLI interfaces with sub-commands

created time in a month

pull request commentcespare/subcmd

Support nested sub-commands

It's okay to get rid of the prefix in PrintDefaults. That probably wasn't a good idea.

However, defaultUsage shouldn't use os.Args. The point of Runner is that it isn't directly connected to global state like os.Args, and the caller can use it in any way they want. For example, if you use subcmd to implement a triply-nested command (./command level1 level2 level3 -xyz) then this approach breaks.

Also, PrintDefaults needs to stay exported. It's part of the public API. This PR should be backwards-compatible; it should only add new things, not take old things away or change the behavior.

I pushed a couple of commits to fix both of these. Let me know if it looks okay and I'll merge it.

rayjcwu

comment created time in a month

push eventrayjcwu/subcmd

Caleb Spare

commit sha 09c428c1221f09a9bdf5f9023c90ec66355343ef

Make default Runner not use os.Args

view details

Caleb Spare

commit sha ba2d16b103830bf3883678b2123f03f383327679

Restore exported API

view details

push time in a month

pull request commentcespare/subcmd

Support nested sub-commands

@rayjcwu Thanks, this is more or less what I was thinking of. I made some changes and added documentation on your branch. Let me know if that looks OK to you and I'll merge.

rayjcwu

comment created time in a month

push eventrayjcwu/subcmd

Caleb Spare

commit sha ee39dcfc2a9f558dd98ae593303febee23ec92eb

Add documentation; restore public API

view details

push time in a month

issue commentcespare/goclj

Use lists instead of vectors for namespace `:import`s

At a glance I think they're all easy.

To call it out, I think all of these are more or less what we've been doing at Liftoff except for

  • Start the contents of :require or :import on a new line after the keyword

Applying that change will touch all our code. (Though the :import change already means we're touching ~half the files, so maybe the marginal impact is minor?)

jwhitbeck

comment created time in a month

create barnchcespare/goclj

branch : how-to-ns

created branch time in a month

issue commentcespare/goclj

Use lists instead of vectors for namespace `:import`s

There are many other recommendations on that page, too. cljfmt already does most of the sorting that "How to ns" talks about, but here are other things which it does not do:

  • Use the order :refer-clojure, then :require, then :import
  • Merge duplicate clauses
  • Use the keywords for these rather than symbols (:require, not require)
  • Use lists for these clauses
  • Use vectors inside :require clauses
  • Use lists inside :import clauses (what this issue is about)
  • Put every :required namespace in a vector, even if there is no :as or :refer
  • Put :referd or :excluded symbols in a vector
  • Start the contents of :require or :import on a new line after the keyword

Should we do all of these?

jwhitbeck

comment created time in a month

issue commentgolang/go

Proposal: add `go test -long`

You can define the -long flag inside your test package and use it as go test -long today.

danderson

comment created time in a month

issue commentgolang/go

proposal: testing: add -shuffle and -shuffleseed to shuffle tests

@josharian I think that means you couldn't write -shuffle N, which would be inconsistent with the other flags. (And generally, it seems better to stick to the flag package's convention where a flag is either boolean or it's not.)

cristaloleg

comment created time in a month

push eventliftoffio/redis

antirez

commit sha 3c2a952912c8d1ffb732008cb9ee49b45a567c21

Merge branch 'oertl-hyperloglog-improvement' into unstable

view details

antirez

commit sha 0b58ad301ef2ef4ecad8e962020f9b676c64e440

CG: Replication WIP 1: XREADGROUP and XCLAIM propagated as XCLAIM.

view details

antirez

commit sha 3cae5f032105125855849a8aae3d3e2fc6872579

CG: XGROUP CREATE/DELCONUSMER replication.

view details

antirez

commit sha ad716e29c03ecce28467b83ab352038fb77933b3

CG: Fix propagate() arg count in streamPropagateXCLAIM().

view details

antirez

commit sha 2ba9a57c9aa5a44d042338518bfd3da30dc60fc3

CG: Add JUSTID to XCLAIM propagation to reduce CPU usage.

view details

antirez

commit sha 5577130451e8ba6ceeac07137f45915a069706a9

CG: Make XINFO Great Again (and more Redis-ish). With XINFO out of the blue I invented a new syntax for commands never used in Redis in the past... Let's fix it and make it Great Again!!11one (TM)

view details

antirez

commit sha 0f2c6b6a18a39443a5260632db84f33957eafff8

Streams: improve MEMORY USAGE computation, include CGs.

view details

antirez

commit sha 233da29f4da7360f691fc491b03278c8d56fe7de

CG: propagate XACK by incrementing server.dirty. This should be more than enough, even if in case of partial IDs that are not found, we send all the IDs to the slave/AOF, but this is definitely a corner case without bad effects if not some wasted space.

view details

zhaozhao.zz

commit sha 11baa8487c9cd0a1f39e13f0b1808cae1cc6757f

anet: avoid double close

view details

zhaozhao.zz

commit sha 46f767aa19f2915cda124575958ea650ec28a12f

fix missed call on freeaddrinfo

view details

charsyam

commit sha 71c7477fd407cc3d0d08ab8dedc564f30776511d

fix memory leak for streamPropagateXCLAIM

view details

Salvatore Sanfilippo

commit sha 3851d30ada437fbeedec70badc7624757f092f21

Merge pull request #4779 from charsyam/feature/fix-streamPropagateXCLAIM fix memory leak for streamPropagateXCLAIM

view details

Salvatore Sanfilippo

commit sha da621783f0cb70ef758542720d987c144427cd3d

Merge pull request #4691 from oranagra/active_defrag_v2 Active defrag v2

view details

Salvatore Sanfilippo

commit sha 7acf0e0a1843c6f50d3c10209a131fdca302502e

Merge pull request #3826 from charsyam/feature/fix_dlopen_leak fix missed dlclose leak in module.c

view details

Salvatore Sanfilippo

commit sha 5d8c89163cdd4105633be1a5dd7a7784775e2143

Merge pull request #4757 from charsyam/feature/fix-invalid-listpack-type-in-makefile fix listpack.c to listpack.o in Makefile

view details

Guy Benoish

commit sha fa00e20b165c5e55f437ceddde9f492cafd38143

Make blocking list commands send keyspace notifications

view details

antirez

commit sha b86c26b2fdbecb62431f1ea7cccfc1b064dfa734

Massivily simplify addReply*() functions in networking.c

view details

antirez

commit sha 6c4cb1670a1f89ec3f38b67638cd76e161195358

Add top comments in two addReply*() functions.

view details

Salvatore Sanfilippo

commit sha 3163c9cb630e6314954f716c9adcd0b689abd41a

Merge pull request #4781 from guybe7/block_list_notify Make blocking list commands send keyspace notifications

view details

Salvatore Sanfilippo

commit sha b38f52169bc261819ce80955f5bfca55b3c950b7

Merge pull request #4777 from soloestoy/avoid-double-close anet: avoid double close

view details

push time in a month

issue commentantirez/redis

cpu affinity

We investigated this issue in early 2018 and it might be useful to describe what we found.

It's of course easy to run redis with whatever affinity settings you want. In our case we found that we got the best performance by pinning each redis process to a single isolated core (using isolcpus). (We also disable irqbalance and spread the interrupt affinity for the NIC's RX queues intentionally as well, taking into account where the redis processes are and the NUMA architecture of the machine.)

The problem you run into with this is that the bgsave process is also pinned to the dedicated redis core. We need it to be on a different, nearby core. The solution we came up with is a small patch which adds a bgsave-cpu-mask configuration option. Then in the config file we can write something like

bgsave-cpu-mask 0000001f00000001

and the bgsave process is run with a different affinity.

This has been working very well for us for the past 20 months. However, as my commit message notes, the patch is a quick'n'dirty workaround that isn't ready to be submitted upstream. It's Linux-specific and has no tests nor documentation. I also don't even know if @antirez wants an option like this.

adriano-di-giovanni

comment created time in a month

push eventliftoffio/redis

Guy Korland

commit sha 8b87876094d8897ecca25cb161b9ceadc975279f

add missing argument to function doc

view details

antirez

commit sha c5e0bc1070f7b8cbe6c2b3467cd03646bcc96318

Modules: dictionary API work in progress #1.

view details

antirez

commit sha bb64c7d8b25b6253172d9af41a600a0640a725d3

Modules: dictionary API work in progress #2: Del API.

view details

antirez

commit sha 14b2f7b033ab7445146ba44940297cb97473aebe

Modules: dictionary API work in progress #3: Iterator creation.

view details

Pavel Skuratovich

commit sha 3a27b3d0d85d56ecd758b56c6af477ae5ff08a76

Fix typo in comment

view details

antirez

commit sha 3968550135f48b8caf3dee76fc50a5e4fe4af1fb

Modules: dictionary API work in progress #4: reseek API.

view details

antirez

commit sha c7e0c410d6b22ae70907bd135f95420f45d3ac89

Modules: change RedisModuleString API to allow NULL context. The burden of having to always create RedisModuleString objects within a module context was too much, especially now that we have threaded operations and modules are doing more interesting things. The context in the string API is currently only used for automatic memory managemnet, so now the API was modified so that the user can opt-out this feature by passing a NULL context.

view details

antirez

commit sha 448d696549dc156fc26f93208d4e2a52d655dcea

Modules: dictionary API work in progress #5: rename API for consistency. By using the "C" suffix for functions getting pointer/len, we can do the same in the future for other modules APIs that need a variant with pointer/len and that are now accepting a RedisModuleString.

view details

antirez

commit sha b6c794acf62223b9b46a14541f3b749969b378bf

Modules: dictionary API WIP #6: implement automatic memory management.

view details

antirez

commit sha 58ac1f8bbe0f705e59b25b40fa00477dd79cc5e9

Modules: dictionary API WIP #7: don't store the context. Storing the context is useless, because we can't really reuse that later. For instance in the API RM_DictNext() that returns a RedisModuleString for the next key iterated, the user should pass the new context, because we may run the keys of the dictionary in a different context of the one where the dictionary was created. Also the dictionary may be created without a context, but we may still demand automatic memory management for the returned strings while iterating.

view details

antirez

commit sha fb1d5717dedf731ed2678b0340b34ea6bcbc64f7

Modules: dictionary API WIP #8: Iterator next/prev.

view details

antirez

commit sha 3ff82790e11bac25db7d0e75d8a27382526161c5

Modules: dictionary API WIP #9: iterator returning string object.

view details

Salvatore Sanfilippo

commit sha cf7475b9b85db45637250ee2cbadba5540760e27

Merge pull request #5377 from Chupaka/patch-1 Fix typo in comment

view details

Salvatore Sanfilippo

commit sha 1d6711a7645cd11bea2e55a438e7a25891117cd6

Merge pull request #5373 from gkorland/patch-5 add missing argument to function doc

view details

antirez

commit sha 1e585d01deb133e1d000cb3cefe4f8e60ab8f129

Modules: dictionary API WIP #10: export API to modules.

view details

antirez

commit sha bec4bfaa0b4bb63336ebbbbf893e3f9db0000423

Merge branch 'unstable' of github.com:/antirez/redis into unstable

view details

antirez

commit sha 6c3bfb00fc17ac1a1c3ba75d2945f8d189415c8f

Modules: fix top comment of hellotimer.c

view details

antirez

commit sha bbe18eacda69797aded8686a63e853b11fd4e222

Modules: remove useless defines in hellotimer.c

view details

antirez

commit sha 880ca077195bdb483d6d7e7b0f8c713dc7a16b67

Modules: hellodict example WIP #1: SET command.

view details

antirez

commit sha 20f047965c1382219616e27afa51d72c0001895c

Modules: hellodict example WIP #1: GET command.

view details

push time in a month

push eventcespare/tsprefix

Caleb Spare

commit sha c6fbd1231d0d050f89b89dfcc99a76b7609c4548

Add -elapsed and -delta flags

view details

push time in a month

issue commentgolang/go

wiki: TestComments

@slewiskelly The CodeReviewComments page has a header at the top which includes, in part:

Please discuss changes before editing this page, even minor ones. Many people have opinions and this is not the place for edit wars.

Should the TestComments page have a similar warning?

slewiskelly

comment created time in 2 months

pull request commentgithub/linguist

Recommend using set/unset gitattributes (vs. true/false strings)

@lildude any thoughts about my last message?

cespare

comment created time in 2 months

issue commentgolang/go

proposal: Go 2: improvements to raw strings

Here is another real life situation that I don't believe has been mentioned yet.

The language defined by text/template uses " and ` for strings, just like Go, with the same semantics.

Inside a template, I want to write a string literal that includes many " characters. To avoid excessive escaping, I wrote the literal using a raw string with backticks. However, the template text is itself inside Go code, so this doesn't work. I ended up doing something like this:

var tmplText = `{{with $json := ` + "`" + `{"hello": "world"}` + "`" + `}}
{{$json}}
{{len $json}}
{{end}}
`

whereas with one of these proposals, I could just directly write the text I want to use. For example, using my favored syntax (@ianlancetaylor's):

var tmplText = ``"{{with $json := `{"hello": "world"}`}}
{{$json}}
{{len $json}}
{{end}}
"``
deanveloper

comment created time in 2 months

push eventcespare/dotfiles

Caleb Spare

commit sha 38536500967a63fb9771de6ec2a2d193d6e9c9b3

Remove overlay-general git ignore pattern

view details

push time in 2 months

issue commentgolang/go

x/tools/gopls: group imports together for the local module

@sushicw Not actively. It's on my to-do list. If you'd like to do it, go ahead.

I expect I'll get to this in the next 1-2 months.

gracenoah

comment created time in 2 months

CommitCommentEvent

issue commentgolang/go

proposal: os: add method (*File).MustClose

Or ioutil.MustClose(io.Closer)?

bradfitz

comment created time in 2 months

issue commentgolang/go

proposal: add "Backlog" milestone

With the current regime, it seems to me that each of these repeatedly-punted issues is likely to get some kind of cursory review once per cycle. Even if most of the time the issue is just moved to the next release milestone, this touch point may lead to it being better-labeled (turning it into a proposal), deprioritized (Unplanned), closed as a duplicate of another issue, or in some cases turned into a real release blocker.

Will there be a comparable regular review of the Backlog issues, either once per cycle or on some other schedule?

If not, then is there a practical difference between Backlog and Unplanned?

If nobody has attached their name to an issue, and it's not tied to a particular release, and it doesn't have another label that causes it to be regularly reviewed (like Proposal), then I don't see it getting worked on with any particular urgency beyond what Unplanned issues see today.

Additionally, I expect that Backlog will become the new catch-all label for anything we don't think is important enough to schedule for the current release -- that is, it will become the new Unplanned. So over time the old low-priority issues will be Unplanned and the newer low-priority issues will be Backlog. (That's assuming there's no regular Backlog review process.)

andybons

comment created time in 2 months

push eventcespare/gg

Caleb Spare

commit sha b14027d882edbd21aeae7142b1598c566476549d

Implement a few more sorting/filtering options

view details

push time in 2 months

push eventcespare/gg

Caleb Spare

commit sha 0f1119ca3f162a2b2d08ef1deedefe6ed7517e79

Update for modules

view details

push time in 2 months

more