Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

* Robert Engels [210608 18:30]: > I think the playground code I supplied is essentially a test case - > and it works in the absence of concurrency or other held references > (like putting it in a map). But it is one simple test case, not an appropriate set of tests. Saying that code passes one

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

I think the playground code I supplied is essentially a test case - and it works in the absence of concurrency or other held references (like putting it in a map). I guess the bottom line for me is that faq says do not mix receiver types. There is either a valid reason for this or it should

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

On Tue, 2021-06-08 at 07:57 -0500, robert engels wrote: > The following code is works fine from the developers perspective: > > https://play.golang.org/p/gC1XsSLvovM > > The developer says, oh cool, I see this great new 3P library that > does background logging - I want to use that instead. Hey, I

[go-nuts] Re: Table-driven benchmarks defeat inlining

On Sunday, June 6, 2021 at 8:35:02 AM UTC-4 Paul S. R. Chisholm wrote: > For example, could this code: > > func BenchmarkPopCountAlive(b *testing.B) { > sum = 0 > for i := 0; i < b.N; i++ { > sum += PopCount(0x1234567890abcdef) > } > } > > hypothetically be optimized to: > >

Re: [go-nuts] Are receiver copies atomic?

Not using gc. You can verify that by running this under the race detector (`go run -race main.go`): package main type A int func (A) M() {} func main() { var a A go func() { a.M() }() a = 1 } Notably, the function doesn't even have to use the receiver (in fact, the receiver is

[go-nuts] Re: Are receiver copies atomic?

I'm not 100% sure what you mean by "copy made atomically" means in this context. But if you mean is calling a value receiver method safe for concurrently, then the answer is no. In fact it can be the source of subtle races. Take for example this simple program

Re: [go-nuts] Re: what type of grammar GO programming language?

wonderful！ 在2011年10月23日星期日 UTC+8 下午3:11:53<⚛> 写道： > On Sat, Oct 22, 2011 at 8:05 PM, Tom (NiftyHat) Mitchell > wrote: > > > > On Sat, Oct 22, 2011 at 1:38 AM, ⚛ <0xe2.0x...@gmail.com> wrote: > > > On Oct 22, 12:14 am, "Tom (NiftyHat) Mitchell" > > > wrote > > :. > > >> ...snip... > > >>

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

* 'Axel Wagner' via golang-nuts [210608 02:54]: > On Tue, Jun 8, 2021 at 6:36 AM Marvin Renich wrote: > > > You say that test cases of Log work fine, but they are only fine in a > > non-concurrent environment. The instant you test Log (without > > interfaces) in a concurrent program it fails

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

OK, I will try one more time. The following code is works fine from the developers perspective: https://play.golang.org/p/gC1XsSLvovM The developer says, oh cool, I see this great new 3P library that does background logging - I want to use that instead.

Re: [go-nuts] Are receiver copies atomic?

On Tue, Jun 8, 2021 at 12:08 PM Ian Davis wrote: > When a method with a non-pointer receiver is called, is the copy made > atomically? My intuition says it must be but perhaps someone else can confirm > it? I don't think the specs require that and I don't think well known implementations try

[go-nuts] Are receiver copies atomic?

This question came to me while reading the recent thread titled "Knowing from documentation whether an interface is holding a pointer or a struct?" When a method with a non-pointer receiver is called, is the copy made atomically? My intuition says it must be but perhaps someone else can confirm

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

On Tue, Jun 8, 2021 at 6:36 AM Marvin Renich wrote: > You say that test cases of Log work fine, but they are only fine in a > non-concurrent environment. The instant you test Log (without > interfaces) in a concurrent program it fails in an obvious manner. > nit: I don't think concurrency has

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

On Tue, Jun 8, 2021 at 3:16 AM Robert Engels wrote: > I like Go. A lot. I’ve designed and built systems with millions of LOC. > Pointing out aspects that might benefit from changes should be encouraged - > if not it’s a religion not a programming language. > FTR, this is the second time you are

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

On Tue, Jun 8, 2021 at 3:16 AM Robert Engels wrote: > Now, I have a struct I want to use with as an EventLogger (badly named - > really EventSource). The code I wrote works fine. Test cases (of Log()) > work fine. > This is where the refusal to acknowledge comes in. It does not work fine. I