peterbourgon

./main.go:36: cannot use myServer literal (type *myServer) as type etcdserverpb.KVServer in assignment:
  *myServer does not implement etcdserverpb.KVServer (wrong type for Compact method)
    have Compact("golang.org/x/net/context".Context, *etcdserverpb.CompactionRequest) (*etcdserverpb.CompactionResponse, error)
    want Compact("github.com/coreos/etcd/vendor/golang.org/x/net/context".Context, *etcdserverpb.CompactionRequest) (*etcdserverpb.CompactionResponse, error)

peterbourgon

package main

import (
	"errors"

	"github.com/coreos/etcd/etcdserver/etcdserverpb"
	"golang.org/x/net/context"
)

type myServer struct{}

peterbourgon

import sublime, sublime_plugin

class PositionListener(sublime_plugin.EventListener):
  def on_selection_modified(self,view):
    text = "Pos:"
    sels = view.sel()
    for s in sels:
        text += " " + str(s.begin())
        if not s.empty():
            text += "-" + str(s.end())

peterbourgon

in re: weaveworks/scope#515 (comment)

Whats the downsides of this approach? I'm not a huge fan of the factory style, if only because it pollutes potentially clean APIs (it would work better if golang had optional parameters...)

The downside is that it pollutes the global namespace—all else equal, our goal should be to have no global state—and makes testing harder, i.e. this

oldStubThing := stubThing
defer func() { stubThing = oldStubThing }()
stubThing = func() Thing { return mockThing{123} }

peterbourgon

package main

import (
	"errors"
	"log"

	"github.com/afex/hystrix-go/hystrix"
)

func main() {

peterbourgon

<ptrb> mattheath: curious if my idea of the interaction between
  Transport and Codec maps to yours... viz.
  http://play.golang.org/p/BgcgWvkSSR

<mattheath> yeah think so

<mattheath> i’d see the codec as the serialisation part between the
  transport (http/zmq/rmq) and the server itself which handles a decoded
  request

peterbourgon

<aybabtme> ptrb: i've thought of storing log entries into context.Context but found it would be too cumbersome `ctx.Value("log").(*log.Entry).Info("message")`
<aybabtme> ptrb: another thing i thought of doing was add a context.Context aware func to our logger, `log.Ctx(ctx).Info("message")`
<aybabtme> ptrb: but then it would mean all the fields in `ctx` would get logged, which im not sure we always want
<aybabtme> responding here to avoid derailing the PR more with my comments =P
<mattheath> what’s the advantage of logging with the context? is the aim being able to correlate specific log lines back to a specific request?
<mattheath> (which would be awesome)
<aybabtme> mattheath: have you read https://github.com/peterbourgon/gokit/pull/4#issuecomment-74424405? might provide ...context...
<aybabtme> =P
<mattheath> "context" nice ;)
<ptrb> aybabtme: I guess it's a tradeoff, do you complect your method definitions or the code within them

peterbourgon

$ cat main.go
package main

var x = "abc"

func main() {
        println(x)
}

$ cat alt.go

peterbourgon

./mysvc \
  -identity foobar \
  -upstream.endpoint "$UPSTREAM_ENDPOINT" \
  -baz.dsn "$BAZ_DSN" \
  -read.timeout "$READ_TIMEOUT" \
  -write.timeout "$WRITE_TIMEOUT" \

# The environment changes based on dev/staging/prod.
# Production might look like e.g.
#

peterbourgon

package main

import (
	"bytes"
	"flag"
	"fmt"
	"log"
	"runtime"
	"sync"