Re: [go-nuts] io.Reader can return (n, err), both non-zero

[Diego Joss]

Sorry I might've been to terse in my previous email.

On Mon, 25 Mar 2024 at 15:19, Tamás Gulácsi  wrote:

> I don't really get it.
> The current documentation says that bespite err!=nil, some data may be
> read (n!=0).
> If one obeys this rule, then it will consume the data, then handle the
> error.
>
> If we change then io.Reader's documentation (and all std lib
> implementations)...
>
> Ok, now I may be understand: If an io.Reader implementation obeys this
> stricter rule, then it would become wrong with the new (lax) rule...
> What about 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):
>
>> Hi
>>
>> On Thu, 21 Mar 2024 at 19:23, 'Christian Stewart' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> When sending Read() via an RPC call or traversing locks, it is
>>> significantly faster to return EOF in the same call as returning the rest
>>> of the available 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.
>>
>
What I meant is that the single RPC (or lock) call is not a valid
justification for the non-exclusive return values of io.Reader.
Let's consider io.Read specification that must return err != nil iff n ==
0, then it is possible to implement it without extra RPC calls by caching
the error value.

-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGjxhKkegNNjL4-79bS%2B7sq3pWJGZsQAhX5Z1y_C%3DU372vAoig%40mail.gmail.com.

Re: [go-nuts] io.Reader can return (n, err), both non-zero

[Diego Joss]

Hi

On Thu, 21 Mar 2024 at 19:23, 'Christian Stewart' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> When sending Read() via an RPC call or traversing locks, it is
> significantly faster to return EOF in the same call as returning the rest
> of the available 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 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/CAGjxhKmmoefO5dY1df5GrirP5t4cdBoqvb%2BMkWdaV3zQ4itYNQ%40mail.gmail.com.

Re: [go-nuts] How to minimize RAM usage during Go binary compilation

[Diego Joss]

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 as data during run time, instead of being embedded and compiled as
> code?
>
> - sean
>

-- 
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/CAGjxhKkk9JoZqiMkZT0YvyOkj4M_5RzTJisYkbMxE_puOYbPuQ%40mail.gmail.com.

Re: [go-nuts] how is xml.Decoder.CharsetReader supposed to be held?

[Diego Joss]

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGjxhKmCJWczpUhtgyWsn0dJ1_E9PcTUBOZW112bGsVQyMZq0g%40mail.gmail.com.

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

[Diego Joss]

Hi John,

On Mon, Mar 28, 2022 at 11:26 PM John  wrote:

> I'm looking to satisfy this:
>
>- If you are in an ACL, you can make a TLS connection
>
>
>- If you are not in an ACL, you can only a TCP connection, but not a
>TLS connection*
>
> * It would be better if it didn't honor TCP either, unless it is a health
> probe


> Basically I want to move my denials into the listener and not in the
> http.Server handlers.


> I thought I was clever recently, trying to do this with:


> func (a *aclListener) Accept() (net.Conn, error) {
> conn, err := a.ln.Accept()
> if err != nil {
> return nil, err
> }


> host, _, err := net.SplitHostPort(conn.RemoteAddr().String())
> if err != nil {
> return nil, fmt.Errorf("connection's remote address(%s) could not be
> split: %s", conn.RemoteAddr().String(), err)
> }


> // The probe connected, so close the connection and exit.
> if a.acls.isProbe(host) {
> log.Printf("TCP probe(%s) connection", host)
> conn.Close()
> return nil, ErrIsProbe
> }


> // Block anything that isn't in our ACL.
> if err := a.acls.ipAuth(host); err != nil {
> return nil, err
> }
> log.Println("accepting connection from: ", conn.RemoteAddr().String())
> return conn, nil
> }


How about (in you (*aclListener).Accept method) looping on
net.Listener.Accept until the connection should pass your ACL. Here is some
overysimple pseudo-code version:

func (a *aclListener) Accept() (net.Conn, error) {
for {
conn, err := a.ln.Accept()
if isGood(conn) {
return conn, nil
}
}
}

The way I like to see it is that the "Accept" method means: "return the
next connection tentative which is 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

-- 
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/CAGjxhKkBD0qUsNv4K5Wjt-wWAtK6jbng6XEs%2BvzZ1-%2BGNnAFgA%40mail.gmail.com.

Re: [go-nuts] Performance issue with os.File.Write

[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 using the syscall write(2) with filedescriptor 1, you'll
probably see very similar (if not identical) results.

Personally I prefer the explicit buffering proposed by the Go standard
library, rather than the implicit one of the C stdio.h header. When I was
starting using C, I've already been bitten by the fact that my fwrites were
being implicitly buffered, until I discovered the setbuf(3) function and
read the documentation. Having different default buffering schemes
depending on the output used (yes stderr is not buffered by default), I
find more confusing.

On Sun, 20 Dec 2020 at 21:32, ben...@gmail.com  wrote:

> And os.Stdout (and friends) are all regular *os.File objects (which as Jan
> said, don't buffer). It was non-intuitive to me that stdout didn't buffer
> by default, because it's such a bad thing for efficiently writing lots of
> output, but I guess it makes sense when you want terminal output to appear
> right away. So I realized it made sense, and gives you more control. And
> it's so easy to wrap it in a bufio.NewWriter() ... Flush() if you need
> buffering.
>
> I ran into this exact same issue when implementing GoAWK ... a 10-line fix
> gave me a 10x speedup.
> https://github.com/benhoyt/goawk/commit/60745c3503ba3d99297816f5c7b5364a08ec47ab
>
> -Ben
>
> On Monday, December 21, 2020 at 12:27:43 AM UTC+13 arn...@gmail.com wrote:
>
>> Ah, that is it, thank you!
>>
>> On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wrote:
>>
>>> On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle 
>>> wrote:
>>>
>>> > TLDR; a simple test program appears to show that Go's (*os.File).Write
>>> is 10x slower than C's fputs (on MacOS).
>>>
>>> Apples and oranges. fputs buffers, os.File does not. Rewrite the
>>> benchmark using bufio.
>>>
>> --
> 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/909fa4da-1c74-4c33-98c1-185e6bae9d40n%40googlegroups.com
> 
> .

-- 
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/CAGjxhKkJHf1BoKFD%2BDvkhJkjS0crC94PJpffW3wbvaZw6fpmfA%40mail.gmail.com.

Re: [go-nuts] Re: implementing macro in plan 9 assembly

[Diego Joss]

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 2020 at 14:38, saurav deshpande <
saurav.deshpande1...@gmail.com> wrote:

> okay, Thank you
>
> On Friday, October 16, 2020 at 6:06:34 PM UTC+5:30 iko...@gmail.com wrote:
>
>> I think you can use nasm assembly through inline ASM in cgo indirectly...
>> Go supports writing .s-files written in Go's internal assembly format,
>> which should be much faster than cgo to compile and is probably preferable,
>> but needs a bit of learning.
>>
>>   *Joop Kiefte* - Chat @ Spike
>> 
>> [image: q9zcd]
>>
>> On October 16, 2020 at 12:30 GMT, saurav deshpande <
>> saurav.des...@gmail.com> wrote:
>>
>> So, is it possible to define functions declared in go and defined in nasm
>> assembly? If yes then can you please share an example.
>>
>> Thank you
>>
>> On Friday, October 16, 2020 at 5:39:33 PM UTC+5:30 iko...@gmail.com
>> wrote:
>>
>>> I don't know how this should actually be done, but remember that the Go
>>> assembly is not actually Plan 9 assembly, it's an abstraction by itself,
>>> meant for internal use first and foremost.
>>>
>>>   *Joop Kiefte* - Chat @ Spike
>>>  [image:
>>> q9y39]
>>>
>>> On October 16, 2020 at 10:20 GMT, saurav deshpande <
>>> saurav.des...@gmail.com> wrote:
>>>
>>>
>>> Thank you for the reply.
>>> I do not understand, actually I am trying to define the fuctions in
>>> plan9 assembly  whoes declaration is done in a go file. I want to use macro
>>> like the macro in nasm, but couldn't understand how to do it.
>>> It would be very helpful if you could give an example.
>>>
>>> Thank you.
>>>
>>>
>>> On Friday, October 16, 2020 at 12:07:23 AM UTC+5:30 al...@pbrane.org
>>> wrote:
>>>
 saurav deshpande  once said:
 > How to implement macro in plan9 assembly? I read the documentation of
 > plan9 assembly but could not find it. Is there any alternative for
 > macro in plan9?

 Assembly language source files are preprocessed just like C source.
 The familiar #define and #include directives should work as expected.

 Anthony

>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/c779e51f-ff41-4686-a843-0830316383c3n%40googlegroups.com
>>> 
>>> .
>>>
>>> --
>> 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...@googlegroups.com.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/79b37153-fcc1-4a5f-85ea-6127d28465d8n%40googlegroups.com
>> 
>> .
>>
>> --
> 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/f1170b24-bcbe-4e2c-8f91-2f992d810203n%40googlegroups.com
> 
> .
>

-- 
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/CAGjxhK%3D20mUXCQboVNNXUosTyxZggitC-bJ%3D%2BMhvLs-x0pk26Q%40mail.gmail.com.