Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
Further to this, you can see that having two diametrically opposite claims (1. UDPConn.Read implements Conn.Read and Conn is a generic stream-oriented network connection cf 2. UDP is not stream oriented) might be somewhat confusing. On Sun, 2019-05-12 at 20:00 -0700, Kurtis Rader wrote: > And the Conn documentation says: "Conn is a generic stream-oriented > network > connection." UDP sockets are not stream-oriented. As Robert has > already > pointed out the Read() method on such an object is a wrapper around > the > read() syscall. Which for a UDP socket is equivalent to recv() with > flags > set to zero. You can't use it to read multiple packets with a single > call. > Nor can you use it to read a packet incrementally. At least on UNIX > like > platforms the excess bytes will be discarded. > -- 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/1557723269.21310.88.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
No worries. Thanks for trying.
Dan
On Sun, 2019-05-12 at 22:10 -0500, robert engels wrote:
> I am sorry if you think I was not helpful, nor friendly - I was
> trying to be both.
>
> That is why I took the time to pass on the relevant documentation,
> and code.
>
> >
> > On May 12, 2019, at 10:04 PM, Dan Kortschak
> > wrote:
> >
> > Thank you. I have reviewed the code. I was hoping for some friendly
> > and
> > helpful input.
> >
> > On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
> > >
> > > As I said, I reviewed the code - which you can do as well. It is
> > > below. At least for “unix-ish” systems - it goes to
> > > syscall.Read()
> > > which is why I linked you to the unix documentation on the
> > > difference
> > > between read() and recv().
> > >
> > > Instead of waiting for someone else to confirm, you can think
> > > about
> > > it logically - sending packet based messages as a stream would
> > > not
> > > work as you have no boundaries, and no ordering guarantees - so
> > > streaming them would be useless - it would require every protocol
> > > on
> > > top of UDP to have embedded length and framing information in
> > > order
> > > to detect packet starts. Not to mention it would be impossible to
> > > read the OOB data (like sender address - since a UDP socket can
> > > receive from multiple senders - so you would have no ability to
> > > know
> > > where the packet came from (unless bound to a single sender).
> > >
> > > udpsock.go -> net.go -> poll/fd_unix.go
> > >
> > > // Read implements io.Reader.
> > > func (fd *FD) Read(p []byte) (int, error) {
> > > if err := fd.readLock(); err != nil {
> > > return 0, err
> > > }
> > > defer fd.readUnlock()
> > > if len(p) == 0 {
> > > // If the caller wanted a zero byte read, return
> > > immediately
> > > // without trying (but after acquiring the readLock).
> > > // Otherwise syscall.Read returns 0, nil which looks
> > > like
> > > // io.EOF.
> > > // TODO(bradfitz): make it wait for readability? (Issue
> > > 15735)
> > > return 0, nil
> > > }
> > > if err := fd.pd.prepareRead(fd.isFile); err != nil {
> > > return 0, err
> > > }
> > > if fd.IsStream && len(p) > maxRW {
> > > p = p[:maxRW]
> > > }
> > > for {
> > > n, err := syscall.Read(fd.Sysfd, p)
> > > if err != nil {
> > > n = 0
> > > if err == syscall.EAGAIN && fd.pd.pollable() {
> > > if err = fd.pd.waitRead(fd.isFile); err
> > > == nil {
> > > continue
> > > }
> > > }
> > >
> > > // On MacOS we can see EINTR here if the user
> > > // pressed ^Z. See issue #22838.
> > > if runtime.GOOS == "darwin" && err ==
> > > syscall.EINTR {
> > > continue
> > > }
> > > }
> > > err = fd.eofError(n, err)
> > > return n, err
> > > }
> > > }
> > >
> > >
> > > >
> > > >
> > > > On May 12, 2019, at 9:37 PM, Dan Kortschak
> > > > wrote:
> > > >
> > > > Yes, I'm aware of all this. However, the net.UDPConn Read
> > > > method
> > > > states
> > > > that it "Read implements the Conn Read method", and does not
> > > > the
> > > > io.Reader interface; net.Conn has the explicit method, not an
> > > > embedding
> > > > of io.Reader.
> > > >
> > > > I'd like to hear from someone who contributed to net.
> > > >
> > > > On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
> > > > >
> > > > >
> > > > > Which is a big problem with the Go “interface”
> > > > > specification…
> > > > >
> > > > > But the de-facto standard is as I stated - if it implements
> > > > > the
> > > > > method it implements the interface. There is no requirement
> > > > > that
> > > > > the
> > > > > method/struct “be documented” to be an implementor - buyer
> > > > > beware!
> > > > >
> > > > > We is also why you should never use method names that collide
> > > > > with
> > > > > “stdlib interfaces” unless you intend them to have the same
> > > > > semantics.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On May 12, 2019, at 8:58 PM, Dan Kortschak > > > > > o>
> > > > > > wrote:
> > > > > >
> > > > > > This is not quite true. The language itself doesn't make
> > > > > > claims
> > > > > > other
> > > > > > than types and method names. However, there are conventions
> > > > > > around
> > > > > > the
> > > > > > semantics of methods in an interface. For example, a Read
> > > > > > method
> > > > > > that
> > > > > > returns 0, nil is allowed for io.Reader, but frowned upon
> > > > > > unless
> > > > > > the
> > > > > > buffer is zero length, and a Read method that fills the
> > > > > > buffer
> > > > > > with
> > > > > > n
> > > > > > bytes and returns n-1 (or n+1), nil is not a correct
> > > > > >
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
I am sorry if you think I was not helpful, nor friendly - I was trying to be
both.
That is why I took the time to pass on the relevant documentation, and code.
> On May 12, 2019, at 10:04 PM, Dan Kortschak wrote:
>
> Thank you. I have reviewed the code. I was hoping for some friendly and
> helpful input.
>
> On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
>> As I said, I reviewed the code - which you can do as well. It is
>> below. At least for “unix-ish” systems - it goes to syscall.Read()
>> which is why I linked you to the unix documentation on the difference
>> between read() and recv().
>>
>> Instead of waiting for someone else to confirm, you can think about
>> it logically - sending packet based messages as a stream would not
>> work as you have no boundaries, and no ordering guarantees - so
>> streaming them would be useless - it would require every protocol on
>> top of UDP to have embedded length and framing information in order
>> to detect packet starts. Not to mention it would be impossible to
>> read the OOB data (like sender address - since a UDP socket can
>> receive from multiple senders - so you would have no ability to know
>> where the packet came from (unless bound to a single sender).
>>
>> udpsock.go -> net.go -> poll/fd_unix.go
>>
>> // Read implements io.Reader.
>> func (fd *FD) Read(p []byte) (int, error) {
>> if err := fd.readLock(); err != nil {
>> return 0, err
>> }
>> defer fd.readUnlock()
>> if len(p) == 0 {
>> // If the caller wanted a zero byte read, return
>> immediately
>> // without trying (but after acquiring the readLock).
>> // Otherwise syscall.Read returns 0, nil which looks
>> like
>> // io.EOF.
>> // TODO(bradfitz): make it wait for readability? (Issue
>> 15735)
>> return 0, nil
>> }
>> if err := fd.pd.prepareRead(fd.isFile); err != nil {
>> return 0, err
>> }
>> if fd.IsStream && len(p) > maxRW {
>> p = p[:maxRW]
>> }
>> for {
>> n, err := syscall.Read(fd.Sysfd, p)
>> if err != nil {
>> n = 0
>> if err == syscall.EAGAIN && fd.pd.pollable() {
>> if err = fd.pd.waitRead(fd.isFile); err
>> == nil {
>> continue
>> }
>> }
>>
>> // On MacOS we can see EINTR here if the user
>> // pressed ^Z. See issue #22838.
>> if runtime.GOOS == "darwin" && err ==
>> syscall.EINTR {
>> continue
>> }
>> }
>> err = fd.eofError(n, err)
>> return n, err
>> }
>> }
>>
>>
>>>
>>> On May 12, 2019, at 9:37 PM, Dan Kortschak
>>> wrote:
>>>
>>> Yes, I'm aware of all this. However, the net.UDPConn Read method
>>> states
>>> that it "Read implements the Conn Read method", and does not the
>>> io.Reader interface; net.Conn has the explicit method, not an
>>> embedding
>>> of io.Reader.
>>>
>>> I'd like to hear from someone who contributed to net.
>>>
>>> On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
Which is a big problem with the Go “interface” specification…
But the de-facto standard is as I stated - if it implements the
method it implements the interface. There is no requirement that
the
method/struct “be documented” to be an implementor - buyer
beware!
We is also why you should never use method names that collide
with
“stdlib interfaces” unless you intend them to have the same
semantics.
>
>
> On May 12, 2019, at 8:58 PM, Dan Kortschak
> wrote:
>
> This is not quite true. The language itself doesn't make claims
> other
> than types and method names. However, there are conventions
> around
> the
> semantics of methods in an interface. For example, a Read
> method
> that
> returns 0, nil is allowed for io.Reader, but frowned upon
> unless
> the
> buffer is zero length, and a Read method that fills the buffer
> with
> n
> bytes and returns n-1 (or n+1), nil is not a correct
> implementation
> of
> io.Reader. Nor is an implementation correct if it retains the
> buffer.
>
> Just as the BDNF is not a complete definition of the grammar of
> the
> language, interface type decls are not complete definitions of
> interfaces.
>
> This is why I am asking.
>
> On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote:
>>
>>
>> There is no claim because that is not how Go interfaces work
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
Thank you, that has clarified what I was wanting to confirm. Dan On Sun, 2019-05-12 at 20:00 -0700, Kurtis Rader wrote: > On Sun, May 12, 2019 at 7:38 PM Dan Kortschak > wrote: > > > > > Yes, I'm aware of all this. However, the net.UDPConn Read method > > states > > that it "Read implements the Conn Read method", and does not the > > io.Reader interface; net.Conn has the explicit method, not an > > embedding > > of io.Reader. > > > And the Conn documentation says: "Conn is a generic stream-oriented > network > connection." UDP sockets are not stream-oriented. As Robert has > already > pointed out the Read() method on such an object is a wrapper around > the > read() syscall. Which for a UDP socket is equivalent to recv() with > flags > set to zero. You can't use it to read multiple packets with a single > call. > Nor can you use it to read a packet incrementally. At least on UNIX > like > platforms the excess bytes will be discarded. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- 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/1557716944.29848.8.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
Thank you. I have reviewed the code. I was hoping for some friendly and
helpful input.
On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
> As I said, I reviewed the code - which you can do as well. It is
> below. At least for “unix-ish” systems - it goes to syscall.Read()
> which is why I linked you to the unix documentation on the difference
> between read() and recv().
>
> Instead of waiting for someone else to confirm, you can think about
> it logically - sending packet based messages as a stream would not
> work as you have no boundaries, and no ordering guarantees - so
> streaming them would be useless - it would require every protocol on
> top of UDP to have embedded length and framing information in order
> to detect packet starts. Not to mention it would be impossible to
> read the OOB data (like sender address - since a UDP socket can
> receive from multiple senders - so you would have no ability to know
> where the packet came from (unless bound to a single sender).
>
> udpsock.go -> net.go -> poll/fd_unix.go
>
> // Read implements io.Reader.
> func (fd *FD) Read(p []byte) (int, error) {
> if err := fd.readLock(); err != nil {
> return 0, err
> }
> defer fd.readUnlock()
> if len(p) == 0 {
> // If the caller wanted a zero byte read, return
> immediately
> // without trying (but after acquiring the readLock).
> // Otherwise syscall.Read returns 0, nil which looks
> like
> // io.EOF.
> // TODO(bradfitz): make it wait for readability? (Issue
> 15735)
> return 0, nil
> }
> if err := fd.pd.prepareRead(fd.isFile); err != nil {
> return 0, err
> }
> if fd.IsStream && len(p) > maxRW {
> p = p[:maxRW]
> }
> for {
> n, err := syscall.Read(fd.Sysfd, p)
> if err != nil {
> n = 0
> if err == syscall.EAGAIN && fd.pd.pollable() {
> if err = fd.pd.waitRead(fd.isFile); err
> == nil {
> continue
> }
> }
>
> // On MacOS we can see EINTR here if the user
> // pressed ^Z. See issue #22838.
> if runtime.GOOS == "darwin" && err ==
> syscall.EINTR {
> continue
> }
> }
> err = fd.eofError(n, err)
> return n, err
> }
> }
>
>
> >
> > On May 12, 2019, at 9:37 PM, Dan Kortschak
> > wrote:
> >
> > Yes, I'm aware of all this. However, the net.UDPConn Read method
> > states
> > that it "Read implements the Conn Read method", and does not the
> > io.Reader interface; net.Conn has the explicit method, not an
> > embedding
> > of io.Reader.
> >
> > I'd like to hear from someone who contributed to net.
> >
> > On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
> > >
> > > Which is a big problem with the Go “interface” specification…
> > >
> > > But the de-facto standard is as I stated - if it implements the
> > > method it implements the interface. There is no requirement that
> > > the
> > > method/struct “be documented” to be an implementor - buyer
> > > beware!
> > >
> > > We is also why you should never use method names that collide
> > > with
> > > “stdlib interfaces” unless you intend them to have the same
> > > semantics.
> > >
> > > >
> > > >
> > > > On May 12, 2019, at 8:58 PM, Dan Kortschak
> > > > wrote:
> > > >
> > > > This is not quite true. The language itself doesn't make claims
> > > > other
> > > > than types and method names. However, there are conventions
> > > > around
> > > > the
> > > > semantics of methods in an interface. For example, a Read
> > > > method
> > > > that
> > > > returns 0, nil is allowed for io.Reader, but frowned upon
> > > > unless
> > > > the
> > > > buffer is zero length, and a Read method that fills the buffer
> > > > with
> > > > n
> > > > bytes and returns n-1 (or n+1), nil is not a correct
> > > > implementation
> > > > of
> > > > io.Reader. Nor is an implementation correct if it retains the
> > > > buffer.
> > > >
> > > > Just as the BDNF is not a complete definition of the grammar of
> > > > the
> > > > language, interface type decls are not complete definitions of
> > > > interfaces.
> > > >
> > > > This is why I am asking.
> > > >
> > > > On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote:
> > > > >
> > > > >
> > > > > There is no claim because that is not how Go interfaces work
--
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
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
On Sun, May 12, 2019 at 7:38 PM Dan Kortschak wrote: > Yes, I'm aware of all this. However, the net.UDPConn Read method states > that it "Read implements the Conn Read method", and does not the > io.Reader interface; net.Conn has the explicit method, not an embedding > of io.Reader. > And the Conn documentation says: "Conn is a generic stream-oriented network connection." UDP sockets are not stream-oriented. As Robert has already pointed out the Read() method on such an object is a wrapper around the read() syscall. Which for a UDP socket is equivalent to recv() with flags set to zero. You can't use it to read multiple packets with a single call. Nor can you use it to read a packet incrementally. At least on UNIX like platforms the excess bytes will be discarded. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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/CABx2%3DD8r%2Bbu-s-L1EanzfNkv9afGwyPSmDWXnX-Y1ZMWCm%3DeRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
As I said, I reviewed the code - which you can do as well. It is below. At
least for “unix-ish” systems - it goes to syscall.Read() which is why I linked
you to the unix documentation on the difference between read() and recv().
Instead of waiting for someone else to confirm, you can think about it
logically - sending packet based messages as a stream would not work as you
have no boundaries, and no ordering guarantees - so streaming them would be
useless - it would require every protocol on top of UDP to have embedded length
and framing information in order to detect packet starts. Not to mention it
would be impossible to read the OOB data (like sender address - since a UDP
socket can receive from multiple senders - so you would have no ability to know
where the packet came from (unless bound to a single sender).
udpsock.go -> net.go -> poll/fd_unix.go
// Read implements io.Reader.
func (fd *FD) Read(p []byte) (int, error) {
if err := fd.readLock(); err != nil {
return 0, err
}
defer fd.readUnlock()
if len(p) == 0 {
// If the caller wanted a zero byte read, return immediately
// without trying (but after acquiring the readLock).
// Otherwise syscall.Read returns 0, nil which looks like
// io.EOF.
// TODO(bradfitz): make it wait for readability? (Issue 15735)
return 0, nil
}
if err := fd.pd.prepareRead(fd.isFile); err != nil {
return 0, err
}
if fd.IsStream && len(p) > maxRW {
p = p[:maxRW]
}
for {
n, err := syscall.Read(fd.Sysfd, p)
if err != nil {
n = 0
if err == syscall.EAGAIN && fd.pd.pollable() {
if err = fd.pd.waitRead(fd.isFile); err == nil {
continue
}
}
// On MacOS we can see EINTR here if the user
// pressed ^Z. See issue #22838.
if runtime.GOOS == "darwin" && err == syscall.EINTR {
continue
}
}
err = fd.eofError(n, err)
return n, err
}
}
> On May 12, 2019, at 9:37 PM, Dan Kortschak wrote:
>
> Yes, I'm aware of all this. However, the net.UDPConn Read method states
> that it "Read implements the Conn Read method", and does not the
> io.Reader interface; net.Conn has the explicit method, not an embedding
> of io.Reader.
>
> I'd like to hear from someone who contributed to net.
>
> On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
>> Which is a big problem with the Go “interface” specification…
>>
>> But the de-facto standard is as I stated - if it implements the
>> method it implements the interface. There is no requirement that the
>> method/struct “be documented” to be an implementor - buyer beware!
>>
>> We is also why you should never use method names that collide with
>> “stdlib interfaces” unless you intend them to have the same
>> semantics.
>>
>>>
>>> On May 12, 2019, at 8:58 PM, Dan Kortschak
>>> wrote:
>>>
>>> This is not quite true. The language itself doesn't make claims
>>> other
>>> than types and method names. However, there are conventions around
>>> the
>>> semantics of methods in an interface. For example, a Read method
>>> that
>>> returns 0, nil is allowed for io.Reader, but frowned upon unless
>>> the
>>> buffer is zero length, and a Read method that fills the buffer with
>>> n
>>> bytes and returns n-1 (or n+1), nil is not a correct implementation
>>> of
>>> io.Reader. Nor is an implementation correct if it retains the
>>> buffer.
>>>
>>> Just as the BDNF is not a complete definition of the grammar of the
>>> language, interface type decls are not complete definitions of
>>> interfaces.
>>>
>>> This is why I am asking.
>>>
>>> On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote:
There is no claim because that is not how Go interfaces work
>
> --
> 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/1557715058.21310.72.camel%40kortschak.io
>
> .
> For more options, visit https://groups.google.com/d/optout
> .
--
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.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
Yes, I'm aware of all this. However, the net.UDPConn Read method states that it "Read implements the Conn Read method", and does not the io.Reader interface; net.Conn has the explicit method, not an embedding of io.Reader. I'd like to hear from someone who contributed to net. On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote: > Which is a big problem with the Go “interface” specification… > > But the de-facto standard is as I stated - if it implements the > method it implements the interface. There is no requirement that the > method/struct “be documented” to be an implementor - buyer beware! > > We is also why you should never use method names that collide with > “stdlib interfaces” unless you intend them to have the same > semantics. > > > > > On May 12, 2019, at 8:58 PM, Dan Kortschak > > wrote: > > > > This is not quite true. The language itself doesn't make claims > > other > > than types and method names. However, there are conventions around > > the > > semantics of methods in an interface. For example, a Read method > > that > > returns 0, nil is allowed for io.Reader, but frowned upon unless > > the > > buffer is zero length, and a Read method that fills the buffer with > > n > > bytes and returns n-1 (or n+1), nil is not a correct implementation > > of > > io.Reader. Nor is an implementation correct if it retains the > > buffer. > > > > Just as the BDNF is not a complete definition of the grammar of the > > language, interface type decls are not complete definitions of > > interfaces. > > > > This is why I am asking. > > > > On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote: > > > > > > There is no claim because that is not how Go interfaces work -- 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/1557715058.21310.72.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
Which is a big problem with the Go “interface” specification… But the de-facto standard is as I stated - if it implements the method it implements the interface. There is no requirement that the method/struct “be documented” to be an implementor - buyer beware! We is also why you should never use method names that collide with “stdlib interfaces” unless you intend them to have the same semantics. > On May 12, 2019, at 8:58 PM, Dan Kortschak wrote: > > This is not quite true. The language itself doesn't make claims other > than types and method names. However, there are conventions around the > semantics of methods in an interface. For example, a Read method that > returns 0, nil is allowed for io.Reader, but frowned upon unless the > buffer is zero length, and a Read method that fills the buffer with n > bytes and returns n-1 (or n+1), nil is not a correct implementation of > io.Reader. Nor is an implementation correct if it retains the buffer. > > Just as the BDNF is not a complete definition of the grammar of the > language, interface type decls are not complete definitions of > interfaces. > > This is why I am asking. > > On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote: >> There is no claim because that is not how Go interfaces work > > -- > 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/1557712717.21310.68.camel%40kortschak.io. > For more options, visit https://groups.google.com/d/optout. -- 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/AFA2FB88-1EA6-44BA-8E3F-A3812633F301%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
This is not quite true. The language itself doesn't make claims other than types and method names. However, there are conventions around the semantics of methods in an interface. For example, a Read method that returns 0, nil is allowed for io.Reader, but frowned upon unless the buffer is zero length, and a Read method that fills the buffer with n bytes and returns n-1 (or n+1), nil is not a correct implementation of io.Reader. Nor is an implementation correct if it retains the buffer. Just as the BDNF is not a complete definition of the grammar of the language, interface type decls are not complete definitions of interfaces. This is why I am asking. On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote: > There is no claim because that is not how Go interfaces work -- 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/1557712717.21310.68.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
There is no claim because that is not how Go interfaces work - if you implement it, you are it - that being said, I wouldn’t use Read() with UDPConn - I would use one of the packet/msg reader methods instead. Read() is a pass through to fd.Read() so it will be implementation dependent, but posix should be that only a single packet is returned. Since UDP is packet oriented, anything else would be unusable, since the packet size forms the boundaries. see http://developerweb.net/viewtopic.php?id=2952 The buffer size controls the size of the OS kernel buffer assigned to the socket - nothing to do with streaming reads. > On May 12, 2019, at 7:20 PM, Dan Kortschak wrote: > > bump? > > On Thu, 2019-05-09 at 16:23 +0930, Dan Kortschak wrote: >> The Conn and UDPConn Read methods look like io.Reader Read methods, >> but >> there is no explicit claim that Conn is an io.Reader. Are the Read >> methods of these two types identical in behaviour to io.Reader? >> Specifically, are the reads allowed to fill the buffer with arbitrary >> numbers of bytes in 0 <= len(p) <= n? >> >> Also, can UPDConn.Read fill the buffer with more than one packet if >> the >> buffer would accommodate that? (I am guessing yes, and that if this >> is >> important then the ReadFrom method should be used). >> >> thanks >> Dan >> > > -- > 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/1557706800.21310.59.camel%40kortschak.io. > For more options, visit https://groups.google.com/d/optout. -- 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/151E5C75-05D9-4448-8858-A3E340009983%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: WASM persistent storage
Hello Agniva! Thanks for the clarification! If I clearly understood the discussion on that issue, there is no current work to implement file I/O nor there are plans to do it in the near future. Do I understand it correctly? If so, the solution should be calling JS to persist the data? Again, thanks for your attention, Luis Otavio Em domingo, 12 de maio de 2019 19:22:01 UTC-3, Agniva De Sarker escreveu: > > There is no file I/O in the browser using Go wasm yet. Please see > https://github.com/golang/go/issues/26051 > > On Sunday, 12 May 2019 13:56:49 UTC+2, Luis Furquim wrote: >> >> Hello, >> >> Is it possible to persist files when using Golang/WASM on a browser? I >> found this page >> https://uncovergame.com/2015/06/06/persisting-data-with-emscripten/ >> showing explaining how to do it using C+EMScripten, but I couldn't find an >> example or documentation in Go. The page doesn't explicit if it does it >> through wasm, but I think it is implied. If it is really possible, someone >> knows how to do it from Go and point me to some documentation? >> >> Thank you in advance. >> >> -- >> Luis Otavio de Colla Furquim >> >> -- 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/d98934a4-ba95-438a-a8c3-526de8df0b01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read
bump? On Thu, 2019-05-09 at 16:23 +0930, Dan Kortschak wrote: > The Conn and UDPConn Read methods look like io.Reader Read methods, > but > there is no explicit claim that Conn is an io.Reader. Are the Read > methods of these two types identical in behaviour to io.Reader? > Specifically, are the reads allowed to fill the buffer with arbitrary > numbers of bytes in 0 <= len(p) <= n? > > Also, can UPDConn.Read fill the buffer with more than one packet if > the > buffer would accommodate that? (I am guessing yes, and that if this > is > important then the ReadFrom method should be used). > > thanks > Dan > -- 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/1557706800.21310.59.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: WASM persistent storage
There is no file I/O in the browser using Go wasm yet. Please see https://github.com/golang/go/issues/26051 On Sunday, 12 May 2019 13:56:49 UTC+2, Luis Furquim wrote: > > Hello, > > Is it possible to persist files when using Golang/WASM on a browser? I > found this page > https://uncovergame.com/2015/06/06/persisting-data-with-emscripten/ > showing explaining how to do it using C+EMScripten, but I couldn't find an > example or documentation in Go. The page doesn't explicit if it does it > through wasm, but I think it is implied. If it is really possible, someone > knows how to do it from Go and point me to some documentation? > > Thank you in advance. > > -- > Luis Otavio de Colla Furquim > > -- 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/8551efab-297f-4c95-a9ee-80fe016a11f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
On May 12, 2019, at 06:55, Jesper Louis Andersen wrote: > > I don't think there are developers who find it unreadable once they know the > logic of that operator. However, if you don't know the rules, then it looks > like black magic. > > In large software developments, consistency beats convenience almost all the > time. You can somewhat easily add another developer, if the notation rules > are consistent. Whereas clever notational convenience costs for every > developer you add to the project. Giving people a choice means you have yet > another section in your style guide to understand and maintain. > > The deeper observation is that in a language with two syntactic classes, > statements and expressions, you can opt to have an if-like evaluation in the > expression class, or you can omit it. Go does the latter, where C does the > former. Of course, you can also define your language with a single syntactic > class. In that case, the above example can be written > > let color = if temperature > 80 then "red" else "green" in ... > > This style is used in a large selection of languages, which people often call > "functional languages". Though the lines of when something fits into the > moniker is somewhat blurry. As it happens, I did get to ask Ken Thompson about his reasoning when he presented at VCF East last weekend. Ken said, as close to verbatim as my week-old memory gets, that they were “too hard to compile right without the possibility of introducing subtle bugs”. I didn’t press further, because there were plenty of people in line to talk to him and I didn’t want to be rude; my assumption is that he was talking about either order of expression execution, or the difficulty of lumping the subexpressions together. He definitely didn’t have anything to say about their potential for abuse or about them being confusing to new programmers, but then we also didn’t talk long. Just adding that since I said I’d ask about it a few weeks ago. BTW, the video of his keynote chat with Brian Kernighan is not to be missed; I was working the audio, so sorry about Brian’s levels, but he was feeding back so I couldn’t turn him up any louder: https://m.youtube.com/watch?v=EY6q5dv_B-o - Dave -- 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/4EF0A6BE-E1A6-4844-A297-07BE31BA07A9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] WASM persistent storage
Hello, Is it possible to persist files when using Golang/WASM on a browser? I found this page https://uncovergame.com/2015/06/06/persisting-data-with-emscripten/ showing explaining how to do it using C+EMScripten, but I couldn't find an example or documentation in Go. The page doesn't explicit if it does it through wasm, but I think it is implied. If it is really possible, someone knows how to do it from Go and point me to some documentation? Thank you in advance. -- Luis Otavio de Colla Furquim -- 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/CACyQ4W4VoFL%3Djr67EhkQAUN4zJA50Zjkdxz2hzb4t%3DZNx4RjbQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go if else syntax .. suggested replacement
I don't think there are developers who find it unreadable once they know the logic of that operator. However, if you don't know the rules, then it looks like black magic. In large software developments, consistency beats convenience almost all the time. You can somewhat easily add another developer, if the notation rules are consistent. Whereas clever notational convenience costs for every developer you add to the project. Giving people a choice means you have yet another section in your style guide to understand and maintain. The deeper observation is that in a language with two syntactic classes, statements and expressions, you can opt to have an if-like evaluation in the expression class, or you can omit it. Go does the latter, where C does the former. Of course, you can also define your language with a single syntactic class. In that case, the above example can be written let color = if temperature > 80 then "red" else "green" in ... This style is used in a large selection of languages, which people often call "functional languages". Though the lines of when something fits into the moniker is somewhat blurry. On Wed, Apr 24, 2019 at 4:08 PM Mark Volkmann wrote: > Are there really developers that find this unreadable? > > color := temperature > 80 ? “red” : “green” > > I know what you are going to say. People will nest them. But even nested > usage can be readable when formatted nicely with one condition per line. > Another alternative is to allow only unnested ternaries. > > R. Mark Volkmann > Object Computing, Inc. > > > On Apr 24, 2019, at 8:58 AM, Jan Mercl <0xj...@gmail.com> wrote: > > > >> On Wed, Apr 24, 2019 at 3:48 PM L Godioleskky > wrote: > >> > >> The lack of a Go ternary operator is at odds with Go's major theme of > clean and easy to read syntax. Those who choose not to use the ternary > operator can always resort back to Go's current 'if -else' or 'case' > syntax. So Go syntax suffers no negative impact by adding the ternary op to > its syntax list. Those opposed to the ternary op should not be allowed to > deny it use other Go programmers, that consider it useful. > > > > That's backwards. Those who has to read the code can no more chose not > > to decrypt the unreadable 4-level nested ternary operations instead of > > 5 if statements. > > > > And to follow on your "logic". If you add to Go even just 10% of what > > people consider useful, it will become a new C++, only much worse. And > > again by your very logic. Why we, that haven't chosen to code in C++ > > in the first place, would be denied by others to use Go, when those > > others have C++ already at hand? > > > > Let everyone use the language he/she likes. Why ruin it for others > > instead of that by forcing Go to become the same as his/her other > > favorite language? > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- J. -- 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/CAGrdgiVQkaDS%2B%3D%2BcSCRFGgK1bpaDJFy6fVAZr5xpMVxv%3D6PNhg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
