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

more universal (I don't even need an object to be a receiver) but maybe an interface is more idiomatic? Thanks, -Shaun -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails fro

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

> Docker add, or whatever is pushing files into your container is probably not respecting timestamps so the .a files are older with respect to .go files (pkg sorts above src) I'm bind-mounting the pkg dir in there so it shouldn't be a question of timestamps (not ruling out something going on th

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

I've started with a clean pkg dir. It's odd; the mtimes look correct (same inside/outside container). the "buildid" to the compile commands s the same on each run too. Does anyone know if there's a way to print out the "StaleReason" that the code collects, that might help me find out what gate

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

Should be able to figure it out from here. -Shaun On Thursday, December 8, 2016 at 8:49:43 PM UTC, Ian Lance Taylor wrote: > > On Thu, Dec 8, 2016 at 10:13 AM, > wrote: > > I've started with a clean pkg dir. > > > > It's odd; the mtimes look correct (sam

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

tween each build) fixed the problem: # Disable cgo so that binaries we build will be fully static. ENV CGO_ENABLED=0 # Recompile the standard library with cgo disabled. This prevents the standard library from being # marked stale, causing full rebuilds every time. RUN go install -v std -Shaun

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

d to do that "just for one build". Not sure what we're looking for here; maybe an optional go.mod override file that can be passed in for just one build? -Shaun -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubsc

[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] 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&#

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

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

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

ght not be being used? I tried running with -x but I can't see any info about freshness (but then I'm not sure what I'm looking for in that output). Thanks, -Shaun -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To u

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: 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.