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

2023-08-14 Thread Pablo Caballero
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

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

2023-05-11 Thread Pablo Caballero
efit 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 think tha

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

2023-05-11 Thread Pablo Caballero
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

Re: [go-nuts] Possible float64 precision problem

2022-03-09 Thread Pablo Caballero
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)

2022-02-04 Thread Pablo Caballero
as 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 taking the time to read and for any insight! Best! Pabl

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

2022-02-04 Thread Pablo Caballero
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

2022-02-04 Thread Pablo Caballero
c.CommandContext(ctx, "cmd.exe", "/c", "start", "/wait", "notepad.exe") c.Stderr = {, ctx} c.Stdout = {, ctx} err := c.Run() fmt.Println("end", "err", err, "stdout", Stdout.String(), "stderr", Stderr.String())

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

2022-02-04 Thread Pablo Caballero
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