[go-nuts] Re: Best practices for upgrading go with existing GOPATH?

I'm sorry to hear that you're having issues. The Go tool should detect that a cached package in $GOPATH/pkg is out of date and overwrite it. If this is not happening reliably this may be a bug. Can you give some details about what you tried, what you expected to happen and what happened

Re: [go-nuts] tool to print dependency graph of /vendor libs

I'll use a concrete example. Substitute with your own. GOPACKAGE=github.com/mkideal/cli { echo "digraph G {"; go list -f '{{ range .Imports }}{{printf "\t%q -> %q;\n" $.ImportPath .}}{{end}}' $(go list -f '{{join .Deps " "}}' $GOPACKAGE) $GOPACKAGE | grep '/.*" -> ".*/'; echo "}"; } | dot

Re: [go-nuts] Re: Why is there no " declared and not used" compile error?

On Wed, Sep 14, 2016 at 11:51 AM, 'simon place' via golang-nuts wrote: > what about when you're writing a lib, can't the importing code make use of > constants? No warning about an unused variable or constant would ever apply to an exported name. That would not

[go-nuts] Re: Why is there no " declared and not used" compile error?

what about when you're writing a lib, can't the importing code make use of constants? On Monday, 12 September 2016 13:57:15 UTC+1, Markus Zimmermann wrote: > > Hi gophers! > > I am wondering why we have a "declared and not used" compile error for > variables

[go-nuts] Best practices for upgrading go with existing GOPATH?

We've recently migrated from Go 1.6 to 1.7 within our engineering team, and have been experiencing some binary compatibility issues (as is to be expected) that have usually been corrected by emptying $GOPATH/pkg and rebuilding - this was recommended but as is the case with manual steps, people

[go-nuts] Re: Why is there no " declared and not used" compile error?

A difference: - it isn't possible to derive the address of a named variable from the address of another named variable - it is possible to derive the value of a named const from another named const const ( a = 0 // b-1, c-2 b = 1 // a+1, c-1 c = 2 // a+2, b+1 )

[go-nuts] Re: Why is there no " declared and not used" compile error?

Am Mittwoch, 14. September 2016 15:43:14 UTC+2 schrieb Markus Zimmermann: > > On Wednesday, September 14, 2016 at 3:37:10 PM UTC+2, Alan Donovan wrote: >> >> On 14 September 2016 at 09:32, Markus Zimmermann >> wrote: >>> >>> Do you think this might be worth bringing up in

Re: [go-nuts] Re: Why is there no " declared and not used" compile error?

On Wed, Sep 14, 2016 at 6:43 AM, Markus Zimmermann wrote: > On Wednesday, September 14, 2016 at 3:37:10 PM UTC+2, Alan Donovan wrote: >> >> On 14 September 2016 at 09:32, Markus Zimmermann wrote: >>> >>> Do you think this might be worth bringing up in

[go-nuts] Re: unmarshaling json to byte type

Not very elegant but: https://play.golang.org/p/m6WFioPURM On Wednesday, September 14, 2016 at 9:06:41 AM UTC-6, Luke wrote: > > Hi, > > i have something like: https://play.golang.org/p/j5WhDMUTI- > > type A struct { >Name string `json:"n"` >Typ byte `json:"t"` > } > > JSON string:

[go-nuts] unmarshaling json to byte type

Hi, i have something like: https://play.golang.org/p/j5WhDMUTI- type A struct { Name string `json:"n"` Typ byte `json:"t"` } JSON string: j := `{"n":"test", "t":"x"}` When I try to do a := A{} json.Unmarshal([]byte(j), ) I get error like: *json: cannot unmarshal string into

[go-nuts] Re: [golang-dev] Gomobile and future interoperability

Typically yes, a program compiled with the NDK keeps working on newer versions of Android. I'm sure there are exceptions but none come to mind. On Wed, Sep 14, 2016 at 10:02 AM, Ged Wed wrote: > > Great thanks David. > > So if i pick version 21 (i think that was kit kat), then

Re: [go-nuts] Can I see all output of `go test` in VIM when i use vim-go plugin?

:!go test works great... thank you On Wednesday, September 14, 2016 at 8:41:15 AM UTC-4, Jan Mercl wrote: > > On Fri, Sep 9, 2016 at 5:43 PM Luke > wrote: > > > I am trying to figure out how to see the whole output of command `go > test` (:GoTest) in VIM... I use vim-go.

[go-nuts] Re: [golang-dev] Gomobile and future interoperability

Great thanks David. So if i pick version 21 (i think that was kit kat), then any android version above that will work ? I am thinking of aiming low initially and see how well that works for the developers calling it from their Java and Swift GUI layers. G On Wed, 14 Sep 2016 at 15:34 David

[go-nuts] Re: Why is there no " declared and not used" compile error?

On Wednesday, September 14, 2016 at 3:37:10 PM UTC+2, Alan Donovan wrote: > > On 14 September 2016 at 09:32, Markus Zimmermann > wrote: >> >> Do you think this might be worth bringing up in golang-dev? >> > > No. We can't make this change to the language without breaking

[go-nuts] Re: Why is there no " declared and not used" compile error?

On Wednesday, September 14, 2016 at 3:47:29 PM UTC+2, Chris Hines wrote: > > On Monday, September 12, 2016 at 8:57:15 AM UTC-4, Markus Zimmermann wrote: >> >> Hi gophers! >> >> I am wondering why we have a "declared and not used" compile error for >> variables

[go-nuts] Re: Why is there no " declared and not used" compile error?

On Monday, September 12, 2016 at 8:57:15 AM UTC-4, Markus Zimmermann wrote: > > Hi gophers! > > I am wondering why we have a "declared and not used" compile error for > variables [https://play.golang.org/p/KLzHVO5L7q] but not for constants [ > https://play.golang.org/p/JG9dSa_VKg]? I am sure

[go-nuts] Re: Why is there no " declared and not used" compile error?

On 14 September 2016 at 09:32, Markus Zimmermann wrote: > > Do you think this might be worth bringing up in golang-dev? > No. We can't make this change to the language without breaking existing programs. -- You received this message because you are subscribed to the Google

[go-nuts] Re: [golang-dev] Gomobile and future interoperability

-golang-dev (which is for discussing the development of Go), +golang-nuts I'm not sure I follow your question. The Android NDK has platform version targets which correspond to particular versions of Android. If you build against a target, you can run on that version of Android or newer. The

[go-nuts] Re: Why is there no " declared and not used" compile error?

On Tuesday, September 13, 2016 at 3:50:12 PM UTC+2, Alan Donovan wrote: > > On 13 September 2016 at 08:22, Markus Zimmermann > wrote: > >> On Monday, September 12, 2016 at 3:41:35 PM UTC+2, adon...@google.com >> wrote: >>> >>> unused constants and types cost nothing at run

[go-nuts] Re: adding aes128-cbc support to ssh.go

On Wednesday, September 14, 2016 at 3:17:19 PM UTC+3, viljo...@gmail.com wrote: > > Hi, > > To start off I'm fairly new to Go, I would just like to know the following: > > If I make changes similar to yours in common.go, how would I be able to > make use of them in my main package. > > For

Re: [go-nuts] Can I see all output of `go test` in VIM when i use vim-go plugin?

Hi Luke, Right now there is no way to see the output. However if you use NeoVim, it connects the stdout to an internal vim terminal and you can see the output directly. In Vim we only parse the error failures and put the inside a quickfix window, so you can go over them and fix them. Regards On

[go-nuts] Re: adding aes128-cbc support to ssh.go

Hi, To start off I'm fairly new to Go, I would just like to know the following: If I make changes similar to yours in common.go, how would I be able to make use of them in my main package. For example in my common.go file I added the following common.go func returnCiphers() []string

[go-nuts] Re: Static race detector?

> > One WIP http://www.doc.ic.ac.uk/~cn06/pub/2016/dingo/ > Man, this is cool! Thanks for the link. They say their deadlock detector only works for unbounded buffers. Nevertheless, this closes a very important gap. If I only think of the years I spent reproducing deadlocks and race

[go-nuts] Copying http.DefaultTransport

I'd like to be able to copy the http.DefaultTransport then tweak it for my app. http.DefaultTransport has a lot of good defaults in, so copying it then tweaking it makes it forward compatible with changes (a good example of a recent change would be the ExpectContinueTimeout). You might think you

Re: [go-nuts] Static race detector?

I don't agree with your latest lines, maybe is cause I miss something but... When analyzing the code the model could distinguish "executors", which cold be goroutines (main - the entry one, g1, g2, etc) or pieces of code under a certain lock variable. If a variable is ONLY accessed by a single

Re: [go-nuts] Having difficulty testing this "cleanly"

Hi All, Firstly, I really appreciate the care and attention everyone is putting into this. I'm finding this challenge fun to navigate. Secondly, I don't feel so silly anymore because clearly this is a non-trivial task. I'm going to have to take a bit to let the last couple of suggestions