Re: [go-nuts] Re: where would one find "go tool tour" with fedora-installed pkgs?

On Wed, 11 Apr 2018, peterGo wrote: > Robert, > > On Ubuntu, I ran, > > $ go get -v -u golang.org/x/tour/... > $ gotour > > Please file a complaint about the missing instructions: > https://github.com/golang/go/issues. done: https://github.com/golang/go/issues/24819 rday -- You received thi

[go-nuts] suggestion for reader exercises throughout the go tour

again, from the perspective of a beginner, a suggestion for the tour to get the reader more involved would be to add simple exercises to some of the pages to get the reader to test things. for example, on the page "Variables with initializers" here: https://tour.golang.org/basics/9 a simple

Re: [go-nuts] suggestion for reader exercises throughout the go tour

On Thu, 12 Apr 2018, Robert P. J. Day wrote: > again, from the perspective of a beginner, a suggestion for the > tour to get the reader more involved would be to add simple > exercises to some of the pages to get the reader to test things. ... snip ... never mind, as i work through more of

[go-nuts] Re: Using log Package with log.Lshortfile Flag

Line 13 is where the method inflog.Println is being passed (not called) - passed to function trace. At that point inflog.Println should be treated just like a value. Then function trace calls inflog.Println (on line number 37). Then method inflog.Println gets deferred (not yet called) and inter

[go-nuts] omitempty by default

Hello Gophers, Is there any way I set omitempty by default for specific json.Encoder or in fallback on global configuration ? Thx in adv. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails f

[go-nuts] net/http: go server requires to read the entire request body before writing response

For HTTP 1.1 with Transfer-Encoding: chunked, the request body is closed if I attempt to write part of the response immediately after receiving the first chunk which is a big problem if you are doing some kind of streaming operation. The following code, reproduces the issue: https://play.golang

[go-nuts] Why does the Response Writer of the http package declare Write rather than embedding io.Writer?

I know that there are no functional differences in them by duck typing. But since the Response package already has dependency on the io package(for example,http.File), so it does not have to lose its dependency, and I do not think that "Write([]byte)(int,error)" of ResponseWriter has a broader me

[go-nuts] Re: Language is a platform, which golang still does not pay attention to !!!

I'm not going to comment on remarks comparing Go and Java, there are certainly many places where Go is way behind although Go is simply not designed as an "all-terrain vehicle" like Java is. However I will comment on your remark comparing Go and PHP: In 2018 the only reason to use PHP over Go i

Re: [go-nuts] Why does the Response Writer of the http package declare Write rather than embedding io.Writer?

On Thu, Apr 12, 2018 at 4:10 AM, bonpi bonpi wrote: > > I know that there are no functional differences in them by duck typing. > But since the Response package already has dependency on the io package(for > example,http.File), so it does not have to lose its dependency, > and I do not think that

[go-nuts] issue ? httptest failed to bind newly released port

Dear all, I filed one issue at https://github.com/golang/go/issues/24818. This issue seems like not happened at regular repeating listen/close calls, but only at httptest. Sincenet.setDefaultListenerSockopts already set this socket option socket.SO_REUSEADDR, I expect app can reuse this por

[go-nuts] Did you try to handle http gzip requests?

Hi guys, I have following code: func handler(w http.ResponseWriter, r *http.Request) { var reader io.Reader switch r.Header.Get("Content-Encoding") { case "gzip": gz, err := gzip.NewReader(r.Body) if err != nil && err.Error() != "EOF" { fmt.Fprintf(w, "error with gzip reader: %s", err.Error()) }

Re: [go-nuts] Did you try to handle http gzip requests?

from the panic you can see that you're passing to ReadAll a valid interface (non-nil type pointer) however the interface contains a nil object (nil value pointer): io/ioutil.ReadAll(0x14ce020, 0x0, 0x0, 0x1a, 0xc420069cb0, 0x1, 0x1) to understand why there are more arguments than you expect in th

Re: [go-nuts] Did you try to handle http gzip requests?

First of all I would like to thank you for your time and willing to help. I've tried to treat error.EOF as real error, but it did not help. What is interesting, when I tried to debug it, everything seems to be fine, from gzip point of view, but when it reaches: body, err := ioutil.ReadAll(reader)

Re: [go-nuts] Did you try to handle http gzip requests?

One suggestion for debugging is to call ioutil.ReadAll() on the Body first (putting it into a bytes.Buffer) then attempt to create a gzip reader from that. That will give you a chance to examine how much and what data exactly you were reading from the client. On Thu, Apr 12, 2018 at 2:05 PM, Yaros

[go-nuts] Correct way to bump a Go library to v2

I am about to bump a Go library to v2. Here are some objectives that I have: 1. New import path for v2 2. Want it to work with go and vgo. 3. Prefer to avoid keeping v1 code around in master branch. (1) and (2) are actually pretty easy. I just put the code in a new v2 dir at the root of my proje

Re: [go-nuts] Correct way to bump a Go library to v2

Hi! On Thu, Apr 12, 2018 at 08:34:28PM -0700, Nick Snyder wrote: > For (3) though, I am a little hesitant to delete the v1 code from master > since this will break people go getting v1. If you wanna support go both for v1 and v2 using current import path then you've no choice - you have to keep

[go-nuts] CGO linker issues

So I am try to get a simple CGO program going with a GO function that can get called back from a 'C' library the error I get is In file included from _cgo_export.c:3: cgo-gcc-export-header-prolog:42:14: error: conflicting types for '_go_Callback' src/smsdk/go_bindings.go:12:12: note: previous

[go-nuts] Did you try to handle http gzip requests?

Is it really needed? I thought body is decompressed automatically. -- 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

[go-nuts] sync.Cond implementation

Hi Gophers! I'm trying to understand line 522 of src/runtime/sema.go : if atomic.Load(&l.wait) == atomic.Load(&l.notify) { > > ... I can't help but thinking, what guarantee that the atomic read of l.wait won't return s