Hi Sandeep,
This is awesome! That is what I was looking for to start.
Many thanks for sharing.
Henri
On Sun, Mar 24, 2019 at 12:55 AM wrote:
> Hi, I have few examples that I developed.
>
> Here is the link: https://github.com/sandeepkalra/mv-backend/
> The auth module shows what you are
From the docs in syscall:// Conn is implemented by some types in the net and os packages to provide
30 // access to the underlying file descriptor or handle.Note, the "some" - meaning it is an optional interface, most likely in the os packages. I've always understood the syscall package to be
The interface is defined in a file in syscall that exists on all platforms:
https://golang.org/src/syscall/net.go?s=219:984#L1.
Any operations you'd want to perform with it would probably invoke
OS-specific APIs, but the same rule applies to using the file descriptor
directly after invoking
File is cross-platform. I am pretty sure no syscall. is guaranteed to be available on any given platform.-Original Message-
From: Matt Layher
Sent: Mar 25, 2019 1:03 PM
To: golang-nuts
Subject: [go-nuts] net.Conn types: File vs SyscallConn method
I've been doing low-level networking
Ah my stuff just never got that big. Thank you!
On Mon, Mar 25, 2019 at 11:23:12AM -0400, Thomas Bushnell, BSG wrote:
> Notice the logic in (*bytes.Buffer).grow which will throw away already read
> data, specifically in the case n <= c/2--m.
>
> On Mon, Mar 25, 2019 at 9:57 AM fREW Schmidt
I've been doing low-level networking work in Go for a few years now, but I
had a realization the other day:
With the addition of the SyscallConn method in Go 1.9 to several
net.Conn/PacketConn types, what is the advantage of using the File method
at this point in time?
The documentation
Go is telling you what is wrong in that message.
You have a file `C:\Users\Gini Joseph\GoWorkspace\pkg\mod\github.com
\stretchr\testify@v1.3.0\mock\mock_test.go` which does not have the
expected "package" line at the top of the file, because the file is empty
(EOF = end of file).
So, as a first
First off, there is something really wrong with your post. Colors make it
almost unreadable. Please stick to non-colored (black) text, and for output
text please paste text directly, or use the code block feature provided by
the google groups website.
Have you looked at the file
In go if i am running the unit test test the follwing error appears
# github.com/emisgroup/auth/lambda/user_service/add_role
package github.com/emisgroup/auth/lambda/user_service/add_role (test)
imports github.com/emisgroup/auth/library/datastore/datastoremocks
imports
When i am running the unit test which was working before stopped working
and i am getting the following error
# github.com/emisgroup/auth/lambda/user_service/add_role
package github.com/emisgroup/auth/lambda/user_service/add_role (test)
imports
Notice the logic in (*bytes.Buffer).grow which will throw away already read
data, specifically in the case n <= c/2--m.
On Mon, Mar 25, 2019 at 9:57 AM fREW Schmidt wrote:
> Oh thanks, I'll switch my code to reader, though as far as I can tell,
> bytes.Buffer doesn't discard already read data,
I think the big difference is that gob is most often for Go to Go serialization (at least easily), where as gRPC is cross-platform RPC mechanism using a cross platform serialization (protobufs).-Original Message-
From: Sameer Ajmani
Sent: Mar 25, 2019 9:53 AM
To: Glen Huang
Cc:
I am very, very, old school, grew up with ASM and Macro Assembly. I really
appreciate this.
I prefer to write Go code in a purely idiomatic way but there are times i
just want to finish the job and ship it.
Thank you for sharing.
On Sunday, March 24, 2019 at 4:23:52 PM UTC-5, Ecstatic Coder
Gob is supported, but I'm not familiar with its current popular use cases.
Most often I see people mapping Go types directly to JSON, but using protos
with gRPC and other places where the compact encoding helps.
On Mon, Mar 25, 2019 at 9:45 AM Glen Huang wrote:
> Thanks for the reply, Sameer.
>
Thanks for the reply, Sameer.
Being able to directly send go types is a really big plus for me, I wonder
if I really want to use gob, are there any recommended rpc choices?
Btw, since grpc + protobuf is the recommended choice right now, does that
mean gob is semi deprecated (or at least on
With gRPC, I recommend you use protobuf.
On Mon, Mar 25, 2019 at 8:18 AM Glen Huang wrote:
> I planed to use net/rpc with gob, but then found the GitHub issue saying
> net/rpc is deprecated, and people should be using grpc instead.
>
> That leads to the question should I use grpc with gob or
Oh thanks, I'll switch my code to reader, though as far as I can tell,
bytes.Buffer doesn't discard already read data, it merely sets the
(private) offset. Maybe I just got luck though.
Thanks again!
On Mon, Mar 25, 2019 at 08:54:43AM +, roger peppe wrote:
> The reason bytes.Buffer doesn't
I planed to use net/rpc with gob, but then found the GitHub issue saying
net/rpc is deprecated, and people should be using grpc instead.
That leads to the question should I use grpc with gob or stick with
protobuf? Google suggests not many people talk about using grpc with gob,
any there
The reason bytes.Buffer doesn't implement io.ReaderAt is that it doesn't
keep bytes in the buffer that have been read, so it's not possible to
implement that method.
You can use bytes.Reader instead, which does implement io.ReaderAt and
io.Seeker.
To make a bytes.Reader from a bytes.Buffer, you
$ go version
go version go1.11.1 darwin/amd64
We have two project : lib-a and project-a
the project-a import lib-a ; if we need Implement a new feature ； we
checkout two new branches : lib-a-love-feature and project-a-love-feature
and project-a-love-feature import the codes in
Is there a reason I shouldn't submit a PR for bytes.Buffer.ReadAt? It
would at least help for some in memory tests.
--
Thanks,
fREW
--
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
21 matches
Mail list logo
