Re: [go-nuts] bytes.Buffer.ReadAt?
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
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?
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
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
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
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... ;)
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
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 Huangwrote: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?
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
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
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
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
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
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?
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
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
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
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..
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.