Re: [go-nuts] bytes.Buffer.ReadAt?

[roger peppe]

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 can do
`bytes.NewReader(buf.Bytes())`.

  hope this helps,
rog.

On Mon, 25 Mar 2019 at 06:06,  wrote:

> 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 it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Question regarding gob

[Glen Huang]

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 aren't many examples demonstrating how to integrate gob into 
grpc. 

I wonder why that's case? Should I use gob or stick with protobuf?

Thanks in advance.

-- 
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.

Re: [go-nuts] bytes.Buffer.ReadAt?

[fREW Schmidt]

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 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 can do
> `bytes.NewReader(buf.Bytes())`.
> 
>   hope this helps,
> rog.
> 
> On Mon, 25 Mar 2019 at 06:06,  wrote:
> 
> > 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 it, send an
> > email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >

-- 
fREW Schmidt
https://blog.afoolishmanifesto.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Question regarding gob

[Sameer Ajmani]

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 stick with
> protobuf? Google suggests not many people talk about using grpc with gob,
> any there aren't many examples demonstrating how to integrate gob into
> grpc.
>
> I wonder why that's case? Should I use gob or stick with protobuf?
>
> Thanks in advance.
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] Question regarding gob

[Glen Huang]

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 hiatus) right now?

On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote:
>
> 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 stick with 
>> protobuf? Google suggests not many people talk about using grpc with gob, 
>> any there aren't many examples demonstrating how to integrate gob into 
>> grpc. 
>>
>> I wonder why that's case? Should I use gob or stick with protobuf?
>>
>> Thanks in advance.
>>
>> -- 
>> 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Question regarding gob

[Sameer Ajmani]

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.
>
> 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 hiatus) right now?
>
> On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote:
>>
>> 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 stick with
>>> protobuf? Google suggests not many people talk about using grpc with gob,
>>> any there aren't many examples demonstrating how to integrate gob into
>>> grpc.
>>>
>>> I wonder why that's case? Should I use gob or stick with protobuf?
>>>
>>> Thanks in advance.
>>>
>>> --
>>> 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.
>>
>>
>>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generis, yet another Generic go code generator... ;)

[David Skinner]

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 wrote:
>
> Just to inform you that I've just released an first version of *Generis*, 
> a lightweight code preprocessor adding the following features to the Go 
> language :
>
>- Generic code definition and instantiation.
>- Conditional compilation.
>- ERB-like HTML templating.
>- Allman to K&R style conversion.
>
> https://github.com/senselogic/GENERIS
>
> It's very similar in function to both Ego and Genny, but implemented as a 
> free-form C++-like preprocessor.
>
> Probably of no use at all for anyone who likes to develop Go code in a 
> purely idiomatic way, which obviously I'm not...
>
>
> *Sample*
>
> package main;
> // -- IMPORTS
> import (
> "html"
> "io"
> "log"
> "net/http"
> "strconv"
> );
> // -- DEFINITIONS
>
> #define DebugMode
> #as true
> // ~~
>
> #define HttpPort
> #as 8080
> // ~~
>
> #define WriteLine( {{text}} )
> #as log.Println( {{text}} )
> // ~~
>
> #define local {{variable}} : {{type}};
> #as var {{variable}} {{type}};
> // ~~
>
> #define DeclareStack( {{type}}, {{name}} )
> #as
> // -- TYPES
>
> type {{name}}Stack struct
> {
> ElementArray []{{type}};
> }
>
> // -- INQUIRIES
>
> func ( stack * {{name}}Stack ) IsEmpty(
> ) bool
> {
> return len( stack.ElementArray ) == 0;
> }
>
> // -- OPERATIONS
>
> func ( stack * {{name}}Stack ) Push(
> element {{type}}
> )
> {
> stack.ElementArray = append( stack.ElementArray, element );
> }
>
> // ~~
>
> func ( stack * {{name}}Stack ) Pop(
> ) {{type}}
> {
> local
> element : {{type}};
>
> element = stack.ElementArray[ len( stack.ElementArray ) - 1 ];
>
> stack.ElementArray = stack.ElementArray[ : len( stack.ElementArray ) 
> - 1 ];
>
> return element;
> }
> #end
> // ~~
>
> #define DeclareStack( {{type}} )
> #as DeclareStack( {{type}}, {{type:PascalCase}} )
> // -- TYPES
> DeclareStack( string )DeclareStack( int32 )
> // -- FUNCTIONS
> func HandleRootPage(
> response_writer http.ResponseWriter,
> request * http.Request
> )
> {
> local
> boolean : bool;
> local
> natural : uint;
> local
> integer : int;
> local
> real : float64;
> local
> escaped_text,
> text : string;
> local
> integer_stack : Int32Stack;
>
> boolean = true;
> natural = 10;
> integer = 20;
> real = 30.0;
> text = "text";
> escaped_text = "";
>
> integer_stack.Push( 10 );
> integer_stack.Push( 20 );
> integer_stack.Push( 30 );
>
> #write response_writer
> 
> 
> 
> 
> <%= request.URL.Path %>
> 
> 
> <% if ( boolean ) { %>
> <%= "URL : " + request.URL.Path %>
> 
> <%@ natural %>
> <%# integer %>
> <%& real %>
> 
> <%~ text %>
> <%= escaped_text %>
> <%= "<%% ignored %%>" %>
> <%% ignored %%>
> <% } %>
> 
> Stack :
> 
> <% for !integer_stack.IsEmpty() { %>
> <%# integer_stack.Pop() %>
> <% } %>
> 
> 
> #end
> }
> // ~~
> func main()
> {
> http.HandleFunc( "/", HandleRootPage );
>
> #if DebugMode
> WriteLine( "Listening on http://localhost:HttpPort"; );
> #end
>
> log.Fatal(
> http.ListenAndServe( ":8080", nil )
> );
> }
>
>

-- 
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.

Re: [go-nuts] Question regarding gob

[Robert Engels]

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: golang-nuts 
Subject: Re: [go-nuts] Question regarding gob

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.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 hiatus) right now?On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote: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 stick with protobuf? Google suggests not many people talk about using grpc with gob, any there aren't many examples demonstrating how to integrate gob into grpc. I wonder why that's case? Should I use gob or stick with protobuf?Thanks in advance.



-- 
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.
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.
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.
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] bytes.Buffer.ReadAt?

['Thomas Bushnell, BSG' via golang-nuts]

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, 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 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 can do
> > `bytes.NewReader(buf.Bytes())`.
> >
> >   hope this helps,
> > rog.
> >
> > On Mon, 25 Mar 2019 at 06:06,  wrote:
> >
> > > 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 it, send
> an
> > > email to golang-nuts+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
>
> --
> fREW Schmidt
> https://blog.afoolishmanifesto.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go Need help _ suddenly all teh unit test in Go Stopped working

[Merry]

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 github.com/emisgroup/auth/library/datastore/datastoremocks
imports github.com/stretchr/testify/mock: 
C:\Users\Gini 
Joseph\GoWorkspace\pkg\mod\github.com\stretchr\testify@v1.3.0\mock\mock_test.go:1:1:
 
expected 'package', found 'EOF'
FAILgithub.com/emisgroup/auth/lambda/user_service/add_role [setup 
failed]
Error: Tests failed.

-- 
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.

[go-nuts] Need Help- Suddenly my unit test stop working

[Merry]

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 github.com/stretchr/testify/mock: 
\GoWorkspace\pkg\mod\github.com\stretchr\testify@v1.3.0\mock\mock_test.go:1:1: 
expected 'package', found 'EOF'
FAILgithub.com/emisgroup/auth/lambda/user_service/add_role [setup 
failed]
Error: Tests failed.

-- 
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.

[go-nuts] Re: Need Help- Suddenly my unit test stop working

[jake6502]

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 "C:\Users\Gini Joseph\GoWorkspace\pkg\mod\
github.com\stretchr\testify@v1.3.0\mock\mock_test.go" and verified that it 
matches https://github.com/stretchr/testify/blob/v1.3.0/mock/mock_test.go ? 
Is it possible that the file was corrupted of modified? Maybe try deleting 
the package and re-downloading?

Also, it might be a good idea to list your go version and platform.


On Monday, March 25, 2019 at 11:42:19 AM UTC-4, Merry wrote:
>
> 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 github.com/stretchr/testify/mock: 
> \GoWorkspace\pkg\mod\github.com\stretchr\testify@v1.3.0\mock\mock_test.go:1:1:
>  
> expected 'package', found 'EOF'
> FAILgithub.com/emisgroup/auth/lambda/user_service/add_role [setup 
> failed]
> Error: Tests failed.
>

-- 
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.

Re: [go-nuts] Go Need help _ suddenly all teh unit test in Go Stopped working

[Marcin Romaszewicz]

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 step, look in that directory and see what's going around.
You might have some corruption in there. It might be easiest to delete your
module cache and try again (`go clean -modcache`)

On Mon, Mar 25, 2019 at 8:40 AM Merry  wrote:

> 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 github.com/emisgroup/auth/library/datastore/datastoremocks
> imports github.com/stretchr/testify/mock:
> C:\Users\Gini Joseph\GoWorkspace\pkg\mod\github.com
> \stretchr\testify@v1.3.0\mock\mock_test.go:1:1: expected 'package', found
> 'EOF'
> FAILgithub.com/emisgroup/auth/lambda/user_service/add_role [setup
> failed]
> Error: Tests failed.
>
> --
> 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.
>

-- 
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.

[go-nuts] net.Conn types: File vs SyscallConn method

[Matt Layher]

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 (https://golang.org/pkg/net/#IPConn.File) mentions:

> File returns a copy of the underlying os.File It is the caller's 
responsibility to close f when finished. Closing c does not affect f, and 
closing f does not affect c.
> 
> The returned os.File's file descriptor is different from the 
connection's. Attempting to change properties of the original using this 
duplicate may or may not have the desired effect.

But the syscall.RawConn provides a handle to a non-dup'd file descriptor, 
which can be used for dealing with socket options and runtime network 
poller-integrated reads/writes. To my knowledge, changing the properties of 
the file descriptor passed in syscall.RawConn methods will always have the 
desired effect, because it offers direct access to the file descriptor.

Which leads to my next question: if SyscallConn provides better 
flexibility, is it time to add a deprecation notice to the File method on 
various package net types, in favor of SyscallConn?

Perhaps there's some benefit to File that I'm not seeing. If so, I'd be 
curious to find out!

Thanks,
Matt Layher (@mdlayher)

-- 
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.

Re: [go-nuts] bytes.Buffer.ReadAt?

[fREW Schmidt]

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  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, 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 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 can do
> > > `bytes.NewReader(buf.Bytes())`.
> > >
> > >   hope this helps,
> > > rog.
> > >
> > > On Mon, 25 Mar 2019 at 06:06,  wrote:
> > >
> > > > 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 it, send
> > an
> > > > email to golang-nuts+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> >
> > --
> > fREW Schmidt
> > https://blog.afoolishmanifesto.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.
> > For more options, visit https://groups.google.com/d/optout.
> >

-- 
fREW Schmidt
https://blog.afoolishmanifesto.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] net.Conn types: File vs SyscallConn method

[Robert Engels]

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 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 (https://golang.org/pkg/net/#IPConn.File) mentions:> File returns a copy of the underlying os.File It is the caller's responsibility to close f when finished. Closing c does not affect f, and closing f does not affect c.> > The returned os.File's file descriptor is different from the connection's. Attempting to change properties of the original using this duplicate may or may not have the desired effect.But the syscall.RawConn provides a handle to a non-dup'd file descriptor, which can be used for dealing with socket options and runtime network poller-integrated reads/writes. To my knowledge, changing the properties of the file descriptor passed in syscall.RawConn methods will always have the desired effect, because it offers direct access to the file descriptor.Which leads to my next question: if SyscallConn provides better flexibility, is it time to add a deprecation notice to the File method on various package net types, in favor of SyscallConn?Perhaps there's some benefit to File that I'm not seeing. If so, I'd be curious to find out!Thanks,Matt Layher (@mdlayher)



-- 
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.




-- 
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.

Re: [go-nuts] net.Conn types: File vs SyscallConn method

[Matt Layher]

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.

So my question still stands, as far as I know.

On Monday, March 25, 2019 at 2:36:29 PM UTC-4, Robert Engels wrote:
>
> 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 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 (https://golang.org/pkg/net/#IPConn.File) mentions:
>
> > File returns a copy of the underlying os.File It is the caller's 
> responsibility to close f when finished. Closing c does not affect f, and 
> closing f does not affect c.
> > 
> > The returned os.File's file descriptor is different from the 
> connection's. Attempting to change properties of the original using this 
> duplicate may or may not have the desired effect.
>
> But the syscall.RawConn provides a handle to a non-dup'd file descriptor, 
> which can be used for dealing with socket options and runtime network 
> poller-integrated reads/writes. To my knowledge, changing the properties of 
> the file descriptor passed in syscall.RawConn methods will always have the 
> desired effect, because it offers direct access to the file descriptor.
>
> Which leads to my next question: if SyscallConn provides better 
> flexibility, is it time to add a deprecation notice to the File method on 
> various package net types, in favor of SyscallConn?
>
> Perhaps there's some benefit to File that I'm not seeing. If so, I'd be 
> curious to find out!
>
> Thanks,
> Matt Layher (@mdlayher)
>
> -- 
> 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 .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] net.Conn types: File vs SyscallConn method

[Robert Engels]

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 implementation specific, and with no guarantees - where as the net package is higher level abstraction and is cross platform.The File abstraction works because a File is already abstract, and so a networking implementation can always return a File implementation, but certain low-level "syscall" specific operations would not be applicable.At least that has been my understanding. I am curious what the designers think.-Original Message-
From: Matt Layher 
Sent: Mar 25, 2019 1:46 PM
To: golang-nuts 
Subject: Re: [go-nuts] net.Conn types: File vs SyscallConn method

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.So my question still stands, as far as I know.On Monday, March 25, 2019 at 2:36:29 PM UTC-4, Robert Engels wrote: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 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 (https://golang.org/pkg/net/#IPConn.File) mentions:> File returns a copy of the underlying os.File It is the caller's responsibility to close f when finished. Closing c does not affect f, and closing f does not affect c.> > The returned os.File's file descriptor is different from the connection's. Attempting to change properties of the original using this duplicate may or may not have the desired effect.But the syscall.RawConn provides a handle to a non-dup'd file descriptor, which can be used for dealing with socket options and runtime network poller-integrated reads/writes. To my knowledge, changing the properties of the file descriptor passed in syscall.RawConn methods will always have the desired effect, because it offers direct access to the file descriptor.Which leads to my next question: if SyscallConn provides better flexibility, is it time to add a deprecation notice to the File method on various package net types, in favor of SyscallConn?Perhaps there's some benefit to File that I'm not seeing. If so, I'd be curious to find out!Thanks,Matt Layher (@mdlayher)



-- 
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.
For more options, visit https://groups.google.com/d/optout.





-- // Conn is implemented by some types in the net and os packages to provide// access to the underlying file descriptor or handle.
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.




-- 
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.

Re: [go-nuts] Re: I am starting Golang and I am looking for a example to Login, Logout, Signup..

[HENRI KNAFO]

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 looking for
>
> Thanks,
> Sandeep Kalra
>
>
> On Tuesday, March 19, 2019 at 7:50:19 PM UTC-4, HENRI KNAFO wrote:
>>
>> Let me first tell you I am new to Golang.
>>
>> I am looking for the code of an example web application with a simple
>> Login, Logout, Signup page (With or without social network login). I tried
>> google and nothing conclusive came out.
>> Obviously I need something to protect against CSRF, hashed password,
>> ect).
>>
>> I am surprise I have trouble finding this since any one starting a
>> project needs this now a days.
>>
>> anyone knows where I can find this?
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/Kl2pKcBb3TA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Henri Knafo
364 Dufferin,
H3X 2Y3
Montreal, Quebec

-- 
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.