[go-nuts] Re: Debugging unit tests in go

I use mostly Printf-based debugging, and still find delve useful at times. Primarily when I'm not sure exactly where in my code a bug arises, so I'll set a couple breakpoints, step through some code, and sometimes find I need to add some debug output in the problem area. If delve had more outp

[go-nuts] Re: Debugging unit tests in go

This is not meant to be snide or flippant. Go actually made me learn Printf based debugging, and I am a much better debugger for it. Add fmt.Printf() to your code. Or use a shortcut function like PP(), which will automatically show where it was called from to. I use a file like vprint.go in all

[go-nuts] Re: [ANN] Get Programming with Go

I may have been pushing my own agenda more than what the Go project is actually about with this: Perhaps something like “Go is designed for programming modern computers and > computer systems in English” would be more accurate? This 2012 talk does indicate that Go is about Google-style network

[go-nuts] Re: My views on Go and why it's better than Scripting

My statement earlier is wrong: The Go 1 compatibility approach may be worth mentioning: programs written > in 2009 will still work in 2019 with the state of the art compiler. Go 1 was actually 2012, not 2009. Also Go 2 may start at some point soon, so maybe "programs written in 2012 will stil

[go-nuts] Re: My views on Go and why it's better than Scripting

Thanks for sharing your experience! On Tuesday, March 6, 2018 at 4:46:54 PM UTC-8, Rich wrote: > > I am a systems administrator. I find it easier and faster to write a > program in Go than it is to script it in Bash. Since writing scripts is > something most Sys Admins do I've had to write them

Re: [go-nuts] tcp net.Conn deadlocks when message size increased

Thanks so much, I had in fact been using buffered readers and writers, for this test and had removed them to make my example more lean, forgetting that the read and write methods behave differently to those of net.Conn. My original problem when using the buffered readers and writers is that I h

Re: [go-nuts] tcp net.Conn deadlocks when message size increased

it deadlocks because you're not reading all the data. Read() may return "up to len(p)", but not necessarily the whole thing. the reader should loop until it reads all available bytes in your case you know how many bytes you are going to write beforehand. if you do not ignore the first value return

Re: [go-nuts] tcp net.Conn deadlocks when message size increased

Read stops reading if it needs to block. https://play.golang.org/p/TwtGzzBEnXV On Fri, Mar 9, 2018 at 8:44 AM, wrote: > Hi all > > I've written a simple program which simply sends a message across a tcp > connection and back again. > > For some reason when I make the buffer larger than a certai

[go-nuts] tcp net.Conn deadlocks when message size increased

Hi all I've written a simple program which simply sends a message across a tcp connection and back again. For some reason when I make the buffer larger than a certain size the program deadlocks. When run on the playground with datalen set to 1 the program deadlocks but with datalen set to

Re: [go-nuts] What major API change really is?

On Fri, Mar 9, 2018 at 6:39 AM, Maxim Ivanov wrote: > > Side question, would hyptohetical future generics substantially > reduce number of API breaking changes? I don't really see how. In a language like Go, I think that any plausible definition of generics implies adding type parameters to a fu

Re: [go-nuts] What major API change really is?

> > Yes, definitely. The only way that *wouldn't* break a reverse dependencies > code is if they'd only use the function with number-literals. Which is > sufficiently unusual to be put very firmly on the "breaking change" side of > things. > And even then it technically breaks, because range o

Re: [go-nuts] What major API change really is?

Yes, definitely. The only way that *wouldn't* break a reverse dependencies code is if they'd only use the function with number-literals. Which is sufficiently unusual to be put very firmly on the "breaking change" side of things. FWIW, I've written

[go-nuts] What major API change really is?

In the light of recent vgo discussion, I was thinking about what would be major change or and what wouldn't. Wanted to ask Goers, in the new better post vgo world, if you changed exported function argument from *int* to *float*, would you release your package as v2? -- You received this m

Re: [go-nuts] glr support in goyacc?

On Fri, Mar 9, 2018 at 12:27 AM, David Wahlstedt wrote: > > But it would still be nice to have GLR in goyacc, for instance in order to > write an ASN.1 parser. I'm not aware of anybody working on that. Ian -- You received this message because you are subscribed to the Google Groups "golang-nu

Re: [go-nuts] Multiple directory paths in $GOPATH and go get

On Fri, Mar 9, 2018 at 5:12 AM, Kaveh Shahbazian wrote: > Thanks! > > The reason for this question: wanted to have one $GOPATH/bin but different > $GOPATH/src. You may be able to use the GOBIN environment variable to do this. See `go help gopath`. Ian > On Friday, March 9, 2018 at 4:33:24 PM

Re: [go-nuts] Multiple directory paths in $GOPATH and go get

Thanks! The reason for this question: wanted to have one $GOPATH/bin but different $GOPATH/src. On Friday, March 9, 2018 at 4:33:24 PM UTC+3:30, ohir wrote: > > On Fri, 9 Mar 2018 04:46:16 -0800 (PST) > Kaveh Shahbazian > wrote: > > > As I understand it's possible to have multiple directory pa

Re: [go-nuts] Multiple directory paths in $GOPATH and go get

On Fri, 9 Mar 2018 04:46:16 -0800 (PST) Kaveh Shahbazian wrote: > As I understand it's possible to have multiple directory paths in > *$GOPATH*, separated by the OS path separator. > > Is there a way to tell *go get* to use the second (nth) item in the path > collection? > No. Go get uses fir

[go-nuts] Multiple directory paths in $GOPATH and go get

As I understand it's possible to have multiple directory paths in *$GOPATH*, separated by the OS path separator. Is there a way to tell *go get* to use the second (nth) item in the path collection? -- You received this message because you are subscribed to the Google Groups "golang-nuts" grou

Re: [go-nuts] glr support in goyacc?

Ok, I see! But it would still be nice to have GLR in goyacc, for instance in order to write an ASN.1 parser. Den torsdag 8 mars 2018 kl. 20:06:44 UTC+1 skrev Jan Mercl: > > On Thu, Mar 8, 2018 at 7:44 PM David Wahlstedt > wrote: > > > So, if golang has been bootstrapped, compiled with itself,