Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

I’ve updated my gist at https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 to use contracts as adaptors. Andy > On Nov 6, 2018, at 8:27 PM, Andy Balholm wrote: > > It is implicit: the functions defined i

[go-nuts] require statements in multi module repositories

Hi all, I've played around with go modules in a multi module repository, and I'm running into oddities. The main confusion is that I have this idea that any package (and its subpackages) that has a go.mod file is a distinct, carved out module that has no relation to its siblings and parent, eve

Re: [go-nuts] Why fmt.Print() debug statements aren't showing up in dev_appserver.py logs?

I believe that the most correct way to do logging with App Engine is to use the log package (https://godoc.org/google.golang.org/appengine/log). This, to my understanding, allows App Engine to categorize logs based on which request they are from alongside some other metadata. Do you see printouts u

[go-nuts] Why fmt.Print() debug statements aren't showing up in dev_appserver.py logs?

The local webserver renders the page correctly at http://localhost:8080/ I"m using the code from https://github.com/GoogleCloudPlatform/golang-samples/tree/master/appengine/helloworld I put a print statement at line 20 of hello.go : fmt.Print(" hello.handle() called")

Re: [go-nuts] goimports performance degrades in go module

On Wed, Nov 7, 2018 at 7:43 PM Joseph Lorenzini wrote: > If have a go.mod, goimports takes 30 seconds to run. If I remove the > go.mod, then goimports takes half a second to run. Is this expected? Is > goimports trying to do something with the packages found in go.mod? Is > there a way to configu

Re: [go-nuts] RE: integration tests and using atom

On Thu, Nov 8, 2018, at 13:49, S Ahmed wrote: > Is there a way to ignore certain tests like my integration tests that setup > db etc. and are long running? I like to add a build tag to my integration tests, something like: // +build integration Then when I want to run them: go test -tags "i

[go-nuts] Re: integration tests and using atom

2018. november 8., csütörtök 20:49:38 UTC+1 időpontban gitted a következőt írta: > > Hi, > Whenever I save a file my go tests run inside of atom. > > Is there a way to ignore certain tests like my integration tests that > setup db etc. and are long running? > > Thanks. > Use T.Short() ti skip lo

[go-nuts] RE: integration tests and using atom

Hi, Whenever I save a file my go tests run inside of atom. Is there a way to ignore certain tests like my integration tests that setup db etc. and are long running? Thanks. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from thi

[go-nuts] code coverage setup for repository holding multiple packages

Hello, a little while ago I've started learning golang. I've created myself a repository holding a variety of things, e.g. data structures and utility functions. I've created separate packages in this repository to can easily navigate between different type of programs. Now, I can't seem to fin

[go-nuts] Re: Why can't I see the whole stack trace of goroutine

> What you really want is the stack trace for the goroutine that created the leaking goroutine, at the time that the leak was created. GODEBUG=tracebackancestors=1 ought to show that. tracebackancestors is new in Go 1.11 IIRC. https://golang.org/pkg/runtime/#hdr-Environment_Variables On Thur

[go-nuts] Re: Why can't I see the whole stack trace of goroutine

I would point out that this *is *the whole stack trace *of the goroutine*. In fact, the actual stack trace is just the first line, since the goroutine in question is only one function deep. If you are breaking into your program after the leaking has started, then the function that created the g

Re: [go-nuts] Re: Why can't I see the whole stack trace of goroutine

If you look at created by net/http.(*Transport).dialConn /usr/local/go/src/net/http/transport.go:1117 +0xa35 It shows you that the go routine is created internally - but it is coming from dialConn() so you need to review all usages of this method. Sometimes when using 3rd party librari

[go-nuts] Re: Why can't I see the whole stack trace of goroutine

Have you tried Ctrl+\ ? That should dump all the goroutines. It also closes the app. If you don't want the app to shut down, then you can take a goroutine profile - https://golang.org/pkg/runtime/pprof/#Profile. On Wednesday, 7 November 2018 09:25:24 UTC+5:30, rickyu...@gmail.com wrote: > > I

Re: [go-nuts] goimports performance degrades in go module

Hi, Could you try the module aware fork of goimports https://github.com/heschik/goimports and let us know if it works and is acceptable speed wise? We are not merging it back yet because we think it may be slower for non module users, and we want some more confidence that it is a drop in replaceme

Re: [go-nuts] goimports performance degrades in go module

+Tools team 30 seconds is much too slow for a tool that's used as a save hook. Ideally we're closer to 100ms; half a second is OK. Do we have a workaround for goimports+go.mod until the latency issues are resolved? Thanks, S On Wed, Nov 7, 2018 at 7:43 PM Joseph Lorenzini wrote: > > > Hi all, >

[go-nuts] Re: module exports

Thanks Pierre. I'd forgotten that feature, documented here: https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit On Thursday, November 8, 2018 at 12:51:05 PM UTC, Pierre Curto wrote: > > If you want to hide packages that you use only for your main package, then >

[go-nuts] Re: module exports

If you want to hide packages that you use only for your main package, then put them under the internal directory within your main package. That way, they are still available from your main package (or any sub package) but not outside of it, including in godoc. i.e. top/ top.go intern

[go-nuts] module exports

Packages are handy for hiding implementation details of a given package from packages that use the given package. However, introducing a package currently has a downside: the package's externals become visible outside the module containing the package. If breaking changes are made to the packag