Re: [go-nuts] Trying to add an `InterfaceOf` to `reflect` package but segmentation violation returned

On Mon, May 23, 2022 at 5:14 PM Wenhua Shi wrote: > > > return New(TypeOf("Interface {}")) > Yes, it gives a string. It doesn't matter here since it's only an edge case. > > > What is the full stack trace Thanks. I don't understand what is going on here: for idx := range funcs {

Re: [go-nuts] Trying to add an `InterfaceOf` to `reflect` package but segmentation violation returned

> return New(TypeOf("Interface {}")) Yes, it gives a string. It doesn't matter here since it's only an edge case. > What is the full stack trace Here it is, ``` === RUN TestInterfaceOf unexpected fault address 0xcb8090 fatal error: fault [signal SIGSEGV: segmentation violation code=0x2 add

Re: [go-nuts] Trying to add an `InterfaceOf` to `reflect` package but segmentation violation returned

On Mon, May 23, 2022 at 9:51 AM Wenhua Shi wrote: > > I'm to create an object (whatever it is) satisfying certain interface > dynamically. There's no way I can do it so I'm thinking maybe I can add a > func in `reflect` package to cover my need. > > The `reflect.StructOf` func creates a struct

[go-nuts] Configuring the environment to create a plugin to attach to an existing project

Hi, I am trying to create a external plugin(buildmode=plugin) to attach Containerd project. I forked Containerd and succeeded in creating and running a plugin in it. However, I would like to build the plugin without forking Containerd, but to do that, it seems that I have to resolve the module de

[go-nuts] Trying to add an `InterfaceOf` to `reflect` package but segmentation violation returned

I'm to create an object (whatever it is) satisfying certain interface dynamically. There's no way I can do it so I'm thinking maybe I can add a func in `reflect` package to cover my need. The `reflect.StructOf` func creates a struct type but without adding methods which gives a good example. I

Re: [go-nuts] Improving safe global variables with generic or inheritance

> that is an atomicity issue Exactly. If you build something that does atomic reads and writes only, you are generally ignoring the larger picture of what sequence of operations needs to be atomic. > Also the `value` entry in the struct is in small cases, prohibiting getting accessed when imp

Fwd: [go-nuts] Improving safe global variables with generic or inheritance

-- Forwarded message - From: Zhaoxun Yan Date: Mon, May 23, 2022 at 6:05 PM Subject: Re: [go-nuts] Improving safe global variables with generic or inheritance To: Brian Candler *That's really essential. For example, using your library, the following code is most definitely *not*

Re: [go-nuts] Improving safe global variables with generic or inheritance

It would be helpful if you could link to actual code, preferably on the playground. That error message seems to indicate that you are not using gotip. I got mixed up earlier, when I wrote Go 1.18. I meant Go 1.19, the next Go version. On Mon, May 23, 2022 at 11:51 AM Zhaoxun Yan wrote: > `&` won

Re: [go-nuts] Improving safe global variables with generic or inheritance

`&` won't make any difference: undefined: atomic.Int32 On Mon, May 23, 2022 at 4:31 PM Axel Wagner wrote: > On Mon, May 23, 2022 at 10:19 AM Zhaoxun Yan > wrote: > >> Yes but the syntax is confusing, e.g. the code below fails: >> > > That's because you can't take the address of a call expres

Re: [go-nuts] Improving safe global variables with generic or inheritance

You could add them as methods. But as I said, I don't think they are good APIs. I think the `Do` I described is the most reasonable compromise, if you really want a one-size-fits-all generic solution. Otherwise, use fine-grained locking or sync/atomic specific to your use-case. On Mon, May 23, 202

Re: [go-nuts] Improving safe global variables with generic or inheritance

type Locked[T any] struct { mu sync.Mutex val T } func (l *Locked[T]) Do(f func(T) T) { l.mu.Lock() defer l.mu.Unlock() l.val = f(l.val) } Could you elaborate how 'Save/Store' , 'Load' and 'Tick / Increase ' get applied to the code above? Thanks. On Mon, May 23, 2022 at 3:2

Re: [go-nuts] Improving safe global variables with generic or inheritance

On Mon, May 23, 2022 at 10:19 AM Zhaoxun Yan wrote: > Yes but the syntax is confusing, e.g. the code below fails: > That's because you can't take the address of a call expression. That is, your code is interpreted as &(a.Load()), while you might have intended (&a).Load()

Re: [go-nuts] Improving safe global variables with generic or inheritance

There are also some changes in there for Go 1.18, specifically the addition of some types, so that only atomic operations can be done: https://pkg.go.dev/sync/atomic@master Yes but the syntax is confusing, e.g. the code below fails: package main import ( "fmt" "sync/atomic" ) var a

Re: [go-nuts] Improving safe global variables with generic or inheritance

FWIW a compromise is to have type Locked[T any] struct { mu sync.Mutex val T } func (l *Locked[T]) Do(f func(T) T) { l.mu.Lock() defer l.mu.Unlock() l.val = f(l.val) } This forces modifications to be under the protection of a mutex while also allowing those modifications to d

Re: [go-nuts] Improving safe global variables with generic or inheritance

> It's best to be intentional about it and explicitly acquire and release a mutex around the critical sections of your code - because ultimately, only your code knows which sections are critical. That's really essential. For example, using your library, the following code is most definitely *n