[go-nuts] I need confirmation about whether I'm in front of a linter false positive.

I started working on a Golang project (from my work). The following pattern makes the company configured linter to complain with: sloppyReassign: re-assignment to `err` can be replaced with `err := myFunc2()` (gocritic) func myFunc() error { ... blah, err := getBlah() if err != nil { return er

Re: [go-nuts] Re: Adding extra files to an already compiled binary using embed.FS

could benefit from the build cache and yet add > something later by merging/fusing multiple io.FS instances at runtime, from > different packages. Deal...? > > On Thursday, May 11, 2023 at 7:09:59 PM UTC+2 Pablo Caballero wrote: > >> Hi folks! I tried to do my homework and I

[go-nuts] Adding extra files to an already compiled binary using embed.FS

Hi folks! I tried to do my homework and I think that the response is "No." I'm just looking for confirmation (maybe I missed something). We are using embed.FS to create "bundles" with a LOT of extra files embedded into the executable. So far so good until we hit a use case where we should be addin

[go-nuts] Avoid forcing my module users' to carry dependencies from code that live under the same repo just as examples/ debugging purposes.

I made a very simple module (the very first one that I uploaded to my GitHub account). I had a main.go file in the root directory used just for testing/debugging (and to keep as an example of how to use the module). Then I "go got" my module from another project just to see that this project transi

Re: [go-nuts] Possible float64 precision problem

Hi Christopher, what input int64 is leading to this result (difference in behavior between Go & C). Does it happen with any input? I'm asking because I'm interested in playing around with this a bit, maybe writing two trivial programs (one on each language) and comparing the machine code generated

[go-nuts] Kill child processes on parent termination (in a cross platform way)

ave to resolve my issue in the short term and was wondering... Does somebody know a 3rd party library currently dealing with this? I couldn't find anything more than an outdated lib that exposes the job APIs ( https://pkg.go.dev/github.com/kolesnikovae/go-winjob/jobapi) Thank you so much for taki

Re: [go-nuts] Re: [windows] c:= exec.CommandContext(ctx, ...) + c.Output() don't return when process is killed upon context expiration until child termination

Fri, Feb 4, 2022 at 12:30 PM Pablo Caballero wrote: > > > > Errata > > > > Go is blocked trying to read from the channel (exec\exec.go): > > > > for range c.goroutine { if err := <-c.errch; err != nil && copyError == > nil { copyError = err } } &g

[go-nuts] Re: [windows] c:= exec.CommandContext(ctx, ...) + c.Output() don't return when process is killed upon context expiration until child termination

uffer c := exec.CommandContext(ctx, "cmd.exe", "/c", "start", "/wait", "notepad.exe") c.Stderr = &ContextWrappedWriter{&Stderr, ctx} c.Stdout = &ContextWrappedWriter{&Stdout, ctx} err := c.Run() fmt.Println("end", "err", err, &q

[go-nuts] [windows] c:= exec.CommandContext(ctx, ...) + c.Output() don't return when process is killed upon context expiration until child termination

Hi, community! The problem is happening in a more complex program but I’ve written a simple program to reproduce it. package main import ( "context" "fmt" "os/exec" "time" ) func main() { ctx, cancel := context.WithTimeout(context.Background(), time.Duration(3)*time.Millisecond) defer c