Re: [go-nuts] Re: slog's use of runtime.Callers() with a skip

> > Do you have any evidence to the contrary? Only that when Go 1.12 dropped, our similar function stopped working and that reducing the skip seemed to do the trick. The symptom was that our function would see an assembly file as the caller, which I interpreted to mean that we'd skipped too far.

Re: [go-nuts] Syscalls that take structs with embedded pointers

> You can use a *byte for the buffer. For instance, unix.Iovec does this Are you sure that's not a bug? What's to stop the *Byte from being moved by the GC? On Fri, May 14, 2021 at 2:27 PM Michael Pratt wrote: > > You can use a *byte for the buffer. For instance, unix.Iovec does this: > https:

Re: [go-nuts] Re: Struggling with go mod, micro-repos and private forks

We have https://golang.org/issue/26232 open for 2FA workflows in general. > > In the meantime, you may need to configure a Personal Access Token > > to > get HTTPS to work. > We

[go-nuts] Re: Struggling with go mod, micro-repos and private forks

l in a way that doesn't fall back to git+ssh mode? - Another team member said they tried using v0.0.0-0001010100- as version but it got replaced. On Thursday, October 24, 2019 at 10:35:32 AM UTC+1, Shaun Crampton wrote: > > >> The good news is that we&#

[go-nuts] Re: Struggling with go mod, micro-repos and private forks

> > > The good news is that we're aware of (and planning to address) most of > these pain points; the bad news is that we haven't been able to get to most > of them yet. > > Great to see, thanks! > >> I think the biggest problem we have is when working with private repos. >> What I want t

[go-nuts] Struggling with go mod, micro-repos and private forks

Hi All, My team own a large product that sprawls across a lot of repos. We also manage a private, commercial fork and we occasionally do new development in private and then merge across to open source. While a monorepo might have been easier to manage, we're stuck with what we've got. We've

[go-nuts] go install seems to do a lot of rebuilding in a container

Hi, I'm trying to optimize the build of my app. Our build times have crept up to ~60s as we've added more dependencies and it's starting to become a problem. The primary problem seems to be that we're building in a container, so we're losing the $GOPATH/pkg cache of build artefacts between bu

Re: [go-nuts] Function pointer vs interface for callback?

Thanks for the tips. On Wed, Oct 12, 2016 at 2:11 PM Jesse McNelis wrote: > On Wed, Oct 12, 2016 at 11:05 PM, wrote: > > Seems like a function > > pointer is more universal (I don't even need an object to be a receiver) > but > > maybe an interface is more idiomatic? > > An interesting patter