[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 err
}
...
if err = myFunc2; err != nil {
return err
}
...
}
What bothers me the most is the fact that if I listen to the linter and
change the code according to its suggestion I get another complaint saying
that I should use the if short version.
Yes, I have found silenced sloppyReassign following this pattern.
What do you think? What linter complaint should I mute? I don't like the
idea of a code base polluted with instructions to tell the linter to shut
up. Do you think I should suggest stopping using linters? :)
Thank you!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAPxFe-utkjMEVrc3DtTR5rmsiEuK8ZLvA6d228PjnroaxRtBkw%40mail.gmail.com.
Re: [go-nuts] Re: Adding extra files to an already compiled binary using embed.FS
Thank you! I'll definitely take a look at that. Best! On Thu, May 11, 2023, 6:08 PM TheDiveO wrote: > What about merging two io.FS instance? A quick search positively surprises > me, as there's https://pkg.go.dev/github.com/yalue/merged_fs for this > already existing. So you 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 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 adding an extra tiny file depending on some user interaction >> to already-built bundles. We: >> * would love to have this extra file in the embedded FS (We want to avoid >> delivering it as an extra file) >> * would love not to have to recompile >> >> Is there any way to achieve that? >> >> Thank you for any help you can provide! >> >> Best >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/782798f0-404d-4546-a72d-b6a01faa9a7bn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/782798f0-404d-4546-a72d-b6a01faa9a7bn%40googlegroups.com?utm_medium=email_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPxFe-sk%3D8QPDcGkoBdZfYgcybVFm_Hw77KWZVNpVAyQi9jp_A%40mail.gmail.com.
[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 adding an extra tiny file depending on some user interaction to already-built bundles. We: * would love to have this extra file in the embedded FS (We want to avoid delivering it as an extra file) * would love not to have to recompile Is there any way to achieve that? Thank you for any help you can provide! Best -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPxFe-sQ24rK4N8Nxkyqi1ktNdCx8fOcH9Hk-tKWfDfynm2_Xg%40mail.gmail.com.
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 from each one. I'm trying to venture into low level debugging/reverse engineering and I think it will be a good exercise. Thank you! Best Pablo On Wed, Mar 9, 2022, 4:39 PM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Wed, 2022-03-09 at 03:37 -0800, christoph...@gmail.com wrote: > > I'm translating a scientific C program into Go that is doing some > > 64bit floating point operations. > > > > In this process I check that the same input yields the same output. > > Unfortunately they don't yield the same result, though the > > computation is simple. It is as follow. I receive a 64bit integer > > value. > > > > This value is converted to float64/double, and divided by 2^64. > > The resulting number is multiplied by 1e8. > > > > With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 > > E6 8E. The last 15bits are different. The computation is performed > > with the same computer. > > > > Could it be that the C program is performing the computation with > > long double (80 bit) precision and that Go is doing it with 64bit > > precision ? > > > > Is there something I could do about it because that might be a red > > flag for replacing the C program with a Go program. > > This is not very surprising depending on the algorithms that are being > used/the problem that is being solved. Some problems are fundamentally > difficult to solve exactly and the nature of floating point makes them > sensitive to the precise set of operations used, intermediate rounding > and the order of operations (even for operations that are commutative > in theory). As Robert said, knowing the C compiler will be important, > and I'd go further, knowing which platform you are building the Go > program on can be important due to differences in how floating point > operations are rendered into machine code by the compiler, or even how > the processor orders apparently commutative operations. > > Assuming the values that you've pasted above are big endian, then the > Go value is within a 1e12th of the value calculate by C ( > https://go.dev/play/p/dn7G2LI75RC). This is not terrible, and maybe > that level of precision is all that can be promised by the algorithm > (and believing digits smaller that 1e-12 is dangerous). Alternatively > there is no fundamental limit at this point and there is a better more > stable algorithm that you can use (though you are only four orders of > magnitude from the machine epsilon > https://en.wikipedia.org/wiki/Machine_epsilon, so be aware). > > Floats are tricky beasts and can easily trip people up. I would suggest > that you read > https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (and > the more friendly https://floating-point-gui.de/). > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/ee58b6e5ad163014b256d249e21c875307fecddb.camel%40kortschak.io > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPxFe-vuCoHfQnZxXLaseYty7672ku0_a1ee3BB4LexOs_qKcA%40mail.gmail.com.
[go-nuts] Kill child processes on parent termination (in a cross platform way)
Hi, community!
I know that I can achieve child processes termination upon parent death
using process groups and the way to do this for POSIX with Golang
(cmd.SysProcAttr = {Setpgid: true}, etc.)
I also know that boost uses this approach for Posix and job objects for
Windows.
I tried to do the homework and realized that Golang's standard library
already exposes the Windows' APIs for job management (however it seems like
they aren't being used "internally")
I'd love to have this integrated "out of the box" with the os/exec stuff
(my exact use case is to launch a process with a context and have it
killed, with all its possible children also killed, on context expiration).
I'd also love to work on that if there is community interest in this
feature but I know that it could be a long way to walk through. So... I
have 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 taking the time to read and for any insight!
Best!
Pablo Caballero
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAPxFe-vi5g99tz8h%3DQsTQ0cYbuUoF8HjK7oarc%3DPpEhyhQvt_w%40mail.gmail.com.
Re: [go-nuts] Re: [windows] c:= exec.CommandContext(ctx, ...) + c.Output() don't return when process is killed upon context expiration until child termination
Hi Ian! Thank you so much for sharing that link with me. It was very
enriching to read it.
As I commented in my first message, the fact that the problem did not occur
on Mac got me a bit confused at first.
Best!
On Friday, February 4, 2022 at 5:42:00 PM UTC-3 Ian Lance Taylor wrote:
> On 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 } }
> >
> > I think that the problem happens if you specify an io.Writer as
> cmd.Stdout and such writer doesn’t satisfy os.File (Output() uses a
> bytes.Buffer internally) because in that case a Pipe is used (to copy data
> between the writer/process). It seems like the pipe is inherited by the
> child process and isn’t closed until the child finish (blocking the
> goroutine that reads from the pipe and writes to the writer even if the
> parent process is gone).
>
> For reference, this class of problems is https://go.dev/issue/23019.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/8ada3531-e6fb-4964-b0a0-d4a68d027ca6n%40googlegroups.com.
[go-nuts] Re: [windows] c:= exec.CommandContext(ctx, ...) + c.Output() don't return when process is killed upon context expiration until child termination
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 } }
I think that the problem happens if you specify an io.Writer as cmd.Stdout
and such writer doesn’t satisfy os.File (Output() uses a bytes.Buffer
internally) because in that case a Pipe is used (to copy data between the
writer/process). It seems like the pipe is inherited by the child process
and isn’t closed until the child finish (blocking the goroutine that reads
from the pipe and writes to the writer even if the parent process is gone).
I got a solution but not sure if it's good enough:
package main import ( "bytes" "context" "fmt" "io" "os/exec" "time" ) type
WriterWithReadFrom interface { io.Writer io.ReaderFrom } type
ContextWrappedWriter struct{ w WriterWithReadFrom c context.Context } type
ReadFromResult struct{ n int64 err error } func (cww *ContextWrappedWriter)
Write(p []byte) (n int, err error){ return cww.Write(p) } func (cww
*ContextWrappedWriter) ReadFrom(r io.Reader) (n int64, err error){ if c, ok
:= r.(io.Closer); ok { ch := make(chan ReadFromResult, 1) go func() { n,
err := cww.w.ReadFrom(r) ch <- ReadFromResult{n, err} }() closed := false
for ;; { select { case res := <-ch: return res.n, res.err case
<-cww.c.Done(): if !closed{ closed = true err := c.Close() if err != nil {
return 0, fmt.Errorf("error closing reader: %v", err) } }
time.Sleep(time.Second * 1) } } } else { return cww.w.ReadFrom(r) } } func
main() { ctx, cancel := context.WithTimeout(context.Background(),
time.Duration(3)*time.Millisecond) defer cancel() var Stdout, Stderr
bytes.Buffer c := exec.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()) }
On Friday, February 4, 2022 at 4:49:41 PM UTC-3 Pablo Caballero wrote:
> 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 cancel() c := exec.CommandContext(ctx,
> "cmd.exe", "/c", "start", "/wait", "notepad.exe") _, err := c.Output()
> fmt.Println("end", "err", err) }
>
> Steps to reproduce:
>
>- Just run the program and observe the process tree (using Process
>Explorer or similar)
>
> Expected behavior: c.Output() call returns as soon as cmd.exe process is
> killed on context timeout.
>
> Observed behavior: the program blocks “forever” on c.Output() call until I
> kill the notepad.exe process manually.
>
> Debugging shows that Go is blocked on (os/exec_windows.go):
>
> s, e := syscall.WaitForSingleObject(syscall.Handle(handle),
> syscall.INFINITE)
>
> waiting on the cmd.exe process handle (even after it was killed).
>
> I also tested on Mac (was curious about the behavior on non-windows OSes)
> and on Mac c.Output() returns as soon as the parent process is killed
> (children process keeps running but it doesn’t cause c.Output() call to
> block)
>
> Thank you in advance!
>
> Best regards!
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/011d6a62-7c98-4d8c-815d-983f18b22165n%40googlegroups.com.
[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 cancel() c := exec.CommandContext(ctx, "cmd.exe", "/c", "start",
"/wait", "notepad.exe") _, err := c.Output() fmt.Println("end", "err", err)
}
Steps to reproduce:
- Just run the program and observe the process tree (using Process
Explorer or similar)
Expected behavior: c.Output() call returns as soon as cmd.exe process is
killed on context timeout.
Observed behavior: the program blocks “forever” on c.Output() call until I
kill the notepad.exe process manually.
Debugging shows that Go is blocked on (os/exec_windows.go):
s, e := syscall.WaitForSingleObject(syscall.Handle(handle),
syscall.INFINITE)
waiting on the cmd.exe process handle (even after it was killed).
I also tested on Mac (was curious about the behavior on non-windows OSes)
and on Mac c.Output() returns as soon as the parent process is killed
(children process keeps running but it doesn’t cause c.Output() call to
block)
Thank you in advance!
Best regards!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/9c4f3404-06f2-4175-8859-16021150050an%40googlegroups.com.
