[go-nuts] Handling EOF when using json.NewDecoder() from named pipe

2023-10-17 Thread Christopher C
Hello all! I'm trying to read json objects from a named pipe. The pipe will be filled intermittently by bash scripts. After the Decode() of the first object, any more calls to Decode() will return EOF. This seems proper since the script has completed, but once it errors with EOF, there doesn

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

2023-10-17 Thread Volker Dobler
Why do you use a json.Decoder? It seems as reading everything (io.ReadAll) until EOF and json.Unmarshal'ling would be a cleaner/simpler solution? V. On Tuesday, 17 October 2023 at 09:10:09 UTC+2 Christopher C wrote: > Hello all! > I'm trying to read json objects from a named pipe. The pipe will

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

2023-10-17 Thread Simon Walter
It is good practice to use test lang/tools/libs/etc different from what you are using in your actual code. If the author has meant for the httptest package as general purpose HTTP testing library, then, I will argue that such defaults are incorrect. It is incorrect even if the intended purpose

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

2023-10-17 Thread Simon Walter
And so: https://github.com/golang/go/issues/63589 On Tuesday, October 17, 2023 at 10:44:04 AM UTC+2 Simon Walter wrote: > It is good practice to use test lang/tools/libs/etc different from what > you are using in your actual code. > > If the author has meant for the httptest package as general p

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

2023-10-17 Thread 'Axel Wagner' via golang-nuts
It is not "meant for tests internal to the http package". It's meant for tests of users of the `net/http` package. That is, implementations of the `http.Handler` interface. In the context of the standard library, that is what "general purpose HTTP testing" means. On Tue, Oct 17, 2023 at 10:44 AM S

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

2023-10-17 Thread Christopher C
I was thinking partial reads could be an issue and the Decoder seemed to do the initial checking for me. Would the ReadAll() be able to recover from EOF state? On Tuesday, October 17, 2023 at 4:37:58 AM UTC-4 Volker Dobler wrote: > Why do you use a json.Decoder? It seems as reading > everything

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

2023-10-17 Thread Marc-Antoine Ruel
Sorry I wasn't clear. The static libraries are in a subdirectory because the user should not care and these libraries are effectively third party code. This declares the generic code available everywhere: https://github.com/periph/d2xx/blob/main/d2xx.go One set of files declare the import that is

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

2023-10-17 Thread 'Brian Candler' via golang-nuts
Are you sure that the writer isn't closing the named pipe between writing JSON objects? If necessary you can check this with strace. I'm pretty sure you'll get an EOF in the *reader* when the *writer* closes from their side. You can demonstrate this with the shell: (In terminal 1) mkfifo /tmp/f

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

2023-10-17 Thread Volker Dobler
On Tuesday, 17 October 2023 at 14:40:47 UTC+2 Christopher C wrote: I was thinking partial reads could be an issue In what regards are "partial reads" less well covered by io.ReadAll than via json.Decoder? and the Decoder seemed to do the initial checking for me. Would the ReadAll() be able t

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

2023-10-17 Thread Justin Israel
On Wednesday, October 18, 2023 at 3:12:29 AM UTC+13 Marc-Antoine Ruel wrote: Sorry I wasn't clear. The static libraries are in a subdirectory because the user should not care and these libraries are effectively third party code. Actually, you were totally clear. Sorry if my comment didn't ma

[go-nuts] Re: go list fails, how do I clear "-mod=readonly"

2023-10-17 Thread Pat Farrell
yes, thanks I updated to the latest go and no longer get the error I'm not sure I understand the output that I'm getting now, but that is a subject for more research on my par On Monday, October 16, 2023 at 5:12:41 PM UTC-4 Jason Phillips wrote: > I believe the fixes have already been released. G

Re: [go-nuts] Generic "nillable" constraint

2023-10-17 Thread Jon Watte
Circling back to this, because it came up today again. Here's the generic function I want to write. It comes up in a lot of function composition, which in turn comes up in a lot of interface adapters and such: func maybeAssign[T any](dst *T, src T, name string) { if *dst != nil { // any can't

Re: [go-nuts] Generic "nillable" constraint

2023-10-17 Thread Bakul Shah
I'd happy with if val { ... } and if !val { ... } Instead of comparing val with an explicit zero but don't feel strongly about this. > On Oct 17, 2023, at 9:09 PM, Jon Watte wrote: > > Circling back to this, because it came up today again. > > Here's the generic function I

Re: [go-nuts] Generic "nillable" constraint

2023-10-17 Thread 'Axel Wagner' via golang-nuts
On Wed, Oct 18, 2023 at 6:09 AM Jon Watte wrote: > Circling back to this, because it came up today again. > > Here's the generic function I want to write. It comes up in a lot of > function composition, which in turn comes up in a lot of interface adapters > and such: > > func maybeAssign[T any](