I did experiment but when using the same client I immediately got an EOF
again. But that might also have been due to the rate-limiting.
I started reading the source code of the http.Client and DefaultTransport
but if any could advice good articles/books about the internals to get the
most out
It is not clear to me from the documentation whether I can continue to use
an http.Client after a POST failed (due to the connection being closed ;
In my case the connection closes probably due to rate-limiting).
The documentation of the http.Transport does mention that, if a network
error occ
>
>
> What you need is a prover that understands the facts holding up the
> callers' stack and can statically detect tautologies in the calees
> checks. Not trivial, but I believe it would be a ton of fun to write
> ;-)
Indeed, that is what I want to achieve.
Are there any of these tools al
but that would enable or disable _all_ precondition checks.
What I am looking for is soth. smart enough that deduces that the
precondition checks in `mul` and `add` can be removed because of the
precondition check in `Muladd`.
On Thursday, March 31, 2022 at 5:26:44 AM UTC+2 Henry wrote:
> You
I like to check the preconditions of a function explicitly by means of code
(instead of only documenting them). Of course this incurs a time-penalty.
When being extremely cautious every function in a call-chain will always
check its preconditions. But for a function down in the call-chain, the
Note from the gorilla websocket documentation ' *SetReadDeadline sets the
read deadline on the underlying network connection. After a read has timed
out, the websocket connection state is corrupt and all future reads will
return an error. A zero value for t means reads will not time out.*'
Th
