gt; 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
>
It's actually already possible: https://go.dev/play/p/75YYs1R94I2
--
Diego
--
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.
t some documentation and an "func io.Read(io.Reader, p) (int,
> error)" wrapper function that caches the error and only returns err!=nil
> iff n!=0 ?
>
> But this maybe just complicate things?
>
> Diego Joss a következőt írta (2024. március 25., hétfő, 10:16:43 UTC+1):
data, than to call Read a second time to get the EOF.
>
Just for sake of discussion/argumentation, it's still possible for the
callee implementation to cache the error status which is returned in the
next Read call. Thus a single RPC (or lock) call is performed.
--
Diego Joss
--
You rece
Or it could be embedded using package embed (https://pkg.go.dev/embed).
Just another candidate solution.
-- Diego
On Wed, 12 Jul 2023 at 14:30, 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> considering it is primarily static information, maybe it should be passed
> in and
Does this work for you?
https://go.dev/play/p/xLRawVhcRtF
-- Diego
--
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
good enough to be accepted". Thus the
meaning of "Accept" for the net.Listener, and your (*aclListener) are not
the same: net.Listener considers as acceptable any connection,
(*aclListener) accepts only connections under certain constraints.
Would this work for you?
-- Diego Joss
--
As Jan said "apples and oranges", in this case comparing *os.Stdout with C
File *stdout is not fair. The equivalent of *os.Stdout in C is the
filedescriptor 1 (STDOUT macro), and the equivalent of *os.Stdout.Write is
write(2) (the syscall), not fwrite or fputs. If you retry your
microbenchmark usin
Have a look at https://golang.org/doc/asm
and examples are always a good source of inspiration. For example
https://golang.org/src/math/dim.go at line 35 defines the prototype for
function Max, which is implemented in assembly in
https://golang.org/src/math/dim_amd64.s
-- Diego
On Fri, 16 Oct 202