[go-nuts] question about 'go vet ' with flag specifying 'analyzer'

Hi, When I run 'go vet' on specific package with the 'analyzer' flag, its behavior seems to depend on where the command is invoked, can anyone please shed a light here, any code pointers that may help me understand the difference is highly appreciated. 1. under /src, -unreachable=false

[go-nuts] Re: go/types: types.Named hides intermediate names

Thanks for the response. I understand that what I'm asking is a bit beyond the scope of what a *compiler* would need to correctly implement the language, which is what the spec details. The question/request here is more about usability of the types package for purposes that are more

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

c := getX() c.x = 1 vs getX().x = 1 On Wed, Nov 20, 2019 at 2:32 PM Robert Engels wrote: > I must of misread something, because this code works fine: > > package main > > import "fmt" > > type X struct { > x int > } > > func getX() X { > var x X > return x > } > > func main() { >

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

Duh, sorry for the spam - I was reading the text without looking at the code. Makes perfect sense. -Original Message- >From: Robert Engels >Sent: Nov 20, 2019 2:31 PM >To: Robert Engels , Ian Lance Taylor , >Orson Cart >Cc: golang-nuts >Subject: Re: [go-nuts] Difference with

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

I must of misread something, because this code works fine: package main import "fmt" type X struct { x int } func getX() X { var x X return x } func main() { c := getX() c.x = 1 fmt.Println(c) } and is what I would expect to happen. Why is this not the same behavior in the other

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

To be honest, I find this very confusing, especially the statement "Changing a field in that copy won't change anything." because even if I have a copy, I should be able to change the fields, and the changes would be there for the scope, and if I returned the copy, whether by address or copy,

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

On Wednesday, 20 November 2019 17:55:59 UTC, Ian Lance Taylor wrote: > > The other kind of answer is that if a function returns a pointer to a > struct, a value of type *employee, then it's normal for that something > else to have a copy of that pointer, perhaps some data structure or > global

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

On Wednesday, 20 November 2019 17:55:00 UTC, Thomas Bushnell, BSG wrote: but the return value of a function is not addressable (it's not a variable, pointer, etc etc). Hi Thomas. Apologies, I said "assignable" when I meant "addressable". I was curious as to why a struct returned from a

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

On Wed, Nov 20, 2019 at 9:41 AM Orson Cart wrote: > > I'm a newbie to Go having used C and C++ in the past and I'm puzzled about > something I've just seen. > > In the following code getEmployee returns a pointer to a struct. The return > value is then dereferenced. This code compiles and runs

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

You can only assign to something which is addressable in the sense of https://golang.org/ref/spec#Address_operators. That is: "either a variable, pointer indirection, or slice indexing operation; or a field selector of an addressable struct operand; or an array indexing operation of an

[go-nuts] Difference with function returning struct and function returning pointer to struct

I'm a newbie to Go having used C and C++ in the past and I'm puzzled about something I've just seen. In the following code getEmployee returns a pointer to a struct. The return value is then dereferenced. This code compiles and runs fine: package main type employee struct { ID int name

Re: [go-nuts] ultra slow os.Exec

On Wed, Nov 20, 2019 at 5:09 AM Robert Engels wrote: > > You should include -r to show the relative time stamps. This would be helpful. Also tell us what the different processes are. I'm guessing that in the fragment above 20441 is wine itself? What is file descriptor 7? Perhaps you could put

Re: [go-nuts] Beginner Questions about C shared library functionality

On Wed, Nov 20, 2019 at 4:14 AM wrote: > > While browsing the examples at https://golang.org/misc/cgo/ I noticed that a > lot of them don't actually specify `package main`. Yet all the C shared lib > tutorials say that all my exported code has to be in `package main`. > > I need to have some

Re: [go-nuts] About Libraries Versioning

Of coarse, sorry for not mentioning it. I still think that this is a major issue. On Wednesday, November 20, 2019 at 3:47:25 PM UTC+2, Jan Mercl wrote: > > On Wed, Nov 20, 2019 at 2:42 PM Eyal > > wrote: > > > The recommended way to create a new version for a go library is by > copying the

[go-nuts] Golang Issue reading/writing Windows Defender Registry

Good day, I have been working with the Golang registry and noticed an issue when attempting to access / read from *SOFTWARE\Microsoft\Windows Defender.* The following code calls *SOFTWARE\Microsoft\Windows NT\CurrentVersion* and it outputs the correct information. winInfo, err :=

Re: [go-nuts] Need help with godbus.

On Tue, Nov 19, 2019 at 5:21 PM Ken Bassford wrote: Please always post source code to the mail list in plain black on white only, thank you. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

Re: [go-nuts] About Libraries Versioning

On Wed, Nov 20, 2019 at 2:42 PM Eyal wrote: > The recommended way to create a new version for a go library is by copying > the library code to a v2 directory. Only if the new version that breaks backward compatibility. Bug fixes and/or new features do not need such switch. -- You received

[go-nuts] About Libraries Versioning

Hi The recommended way to create a new version for a go library is by copying the library code to a v2 directory. I am against this approach from the following reasons: 1. Code duplication: harder to back port fixes, harder to follow, not "nice".

[go-nuts] Re: Need help with godbus.

Hi Folks, Made some progress. I removed the "Foo" routine (it was the last call I made to Export()) and the "Ping" routine I added using the above routine worked. So it would appear that each call to Export() overwrites the last, thus it is not cumilitive as I had expected. Now I'm focused

Re: [go-nuts] ultra slow os.Exec

You should include -r to show the relative time stamps. This would be helpful. > On Nov 20, 2019, at 1:58 AM, miha.vrhov...@gmail.com wrote: > >  > The first wait is on read, the 2nd on futex > [pid 20441] read(5, > "\0\0\0@\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) =

[go-nuts] Re: mutual TLS authentication (sometimes)

How did I miss that?! Awesome, thanks! On Wed, Nov 20, 2019 at 4:17 AM Anthony Martin wrote: > Matthew Zimmerman once said: > > I've also thought about authenticating on a different domain name > > auth.service then redirecting to data.service or something like that > where > > the cookie

[go-nuts] Beginner Questions about C shared library functionality

While browsing the examples at https://golang.org/misc/cgo/ I noticed that a lot of them don't actually specify `package main`. Yet all the C shared lib tutorials say that all my exported code has to be in `package main`. I need to have some code translating between Go and C, do I really have

[go-nuts] Re: go/types: types.Named hides intermediate names

Addendum: this may be surprising from the point of view of object-oriented programming, class inheritance etc. but at risk of stating the obvious, in Go there is no class inheritance: type X time.Time creates a new type X that is (almost) completely unrelated to time.Time: 1. the new type X

[go-nuts] Re: go/types: types.Named hides intermediate names

It's part of the language specifications https://golang.org/ref/spec#Types. It says: type ( B1 string B2 B1 ) "The underlying type of [...] B1 and B2 is string" In other words, when you write type X time.Time there is absolutely *no direct* connection between the types X and time.Time:

[go-nuts] Re: mutual TLS authentication (sometimes)

Matthew Zimmerman once said: > I've also thought about authenticating on a different domain name > auth.service then redirecting to data.service or something like that where > the cookie would be issued to the *.service domain, however that's still > one tls.Config and using SNI with