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
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:
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
> hel
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 th
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 li
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 Co
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
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 a
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
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 leng
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 posi
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, t
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 r
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.co
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 conv
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
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 develope
17 matches
Mail list logo
