Re: [go-nuts] net/http: no Client API to close server connection based on Response #21978

2024-04-04 Thread Jim Minter
other requests in flight (on different connections I assume) - > let those continue - just put any new requests on a new transport for that > host (after a 500 error is encountered) - then tear down the bad when it > has no more requests being processed. > > On Apr 3, 2024, at 1:50 

Re: [go-nuts] net/http: no Client API to close server connection based on Response #21978

2024-04-03 Thread Jim Minter
direct violation of > GotConnInfo’s doc). I would expect this to error out anything inflight, but > otherwise be benign (though I have not checked :) ). > > -eli > > On Apr 2, 2024, at 3:29 PM, Jim Minter wrote: > > Hello, > > I was wondering if anyone had any i

Re: [go-nuts] net/http: no Client API to close server connection based on Response #21978

2024-04-02 Thread Jim Minter
you already know the server is problematic, you could just set Close > on the original request. > > On Tue, Apr 2, 2024, 15:29 Jim Minter wrote: > >> Hello, >> >> I was wondering if anyone had any ideas about >> https://github.com/golang/go/issues/21978 ("

[go-nuts] net/http: no Client API to close server connection based on Response #21978

2024-04-02 Thread Jim Minter
Hello, I was wondering if anyone had any ideas about https://github.com/golang/go/issues/21978 ("net/http: no Client API to close server connection based on Response") -- it's an old issue, but it's something that's biting me currently and I can't see a neat way to solve it. As an HTTP

Re: [go-nuts] [generics] instantiation of structs within generic functions

2023-06-08 Thread Jim Minter
On Thursday, 8 June 2023 at 22:23:51 UTC-6 Ian Lance Taylor wrote: On Thu, Jun 8, 2023 at 8:59 PM Jim Minter wrote: > > I'm rather confused by instantiation of structs in generic functions. I happen to be using go protobufs. Unlike with `json.Unmarshal`, `proto.Unmarshal` expects to r

[go-nuts] [generics] instantiation of structs within generic functions

2023-06-08 Thread Jim Minter
Hi, I'm rather confused by instantiation of structs in generic functions. I happen to be using go protobufs. Unlike with `json.Unmarshal`, `proto.Unmarshal` expects to receive a fully pre-instantiated struct to unmarshal into. The non-generic case looks like this: var _ proto.Message =

Re: [go-nuts] Go modules replace statements referencing legacy codebases

2020-11-07 Thread Jim Minter
Hi, I don't fully understand why we have to use replace directives (I'm still learning my way around go modules), but I have tried extensively to remove them and I can't get go mod to honour an acceptable set of versions in the requirement. I am guessing at a few potential reasons why this

[go-nuts] Re: Go modules replace statements referencing legacy codebases

2020-11-06 Thread Jim Minter
Sadly not. Doing this doesn't cause an error, but it also doesn't change the relevant replace directive in the go.mod file. Jim -- 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,

[go-nuts] Go modules replace statements referencing legacy codebases

2020-11-06 Thread Jim Minter
...etc... go get -u ./... I'm wondering: is there a better way? Should there be? Many thanks! Jim Minter -- 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

[go-nuts] Pruning unused methods

2017-11-08 Thread Jim Minter
guarantee a working binary at the end, but it provides an upper bound figure that suggests to me that there are potentially substantial and worthwhile savings to be had against larger binary sizes by improving the pruning code if possible. Regards, Jim Minter [1] https://github.com/