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

[Sokolov Yura]

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

[go-nuts] CGO linker issues

[rob]

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 declaration is here
_cgo_export.c:17:7: error: conflicting types for '_go_Callback'
src/smsdk/go_bindings.go:12:12: note: previous declaration is here

The code is simple looks like this

package smsdk

/*
#cgo CFLAGS: -Damd64 -D SM_SDK_INTERNAL -I ${SRCDIR}/smsdk
#cgo LDFLAGS: -L${SRCDIR} -lsm_sdk
#include 
#include 
#include "sm_sdk.h"

extern int _go_Callback(int speaking_state);

static void Callback(Handle h, void * caller_context)
{
int val = CLibraryFunction(h);
_go_Callback(val);
}
*/
import "C"
import (
"unsafe"
"sync"
)

var _registeredCallback func(int)

//export _go_SpeakingStateCallback
func _go_SpeakingStateCallback(val int) int {

if _registeredCallback != nil {
_registeredCallback(val)
return 1
}
return 0
}

Any suggestions? 

-- 










"This communication is confidential and may contain privileged 
and/or copyright material. If you are not the intended recipient you must 
not use, disclose, copy or retain it. If you have received it in error 
please immediately notify me by return email, delete the emails and destroy 
any hard copies. Soul Machines Limited does not guarantee the integrity of 
this communication, or that it is free from errors, viruses or 
interference."


*Please consider the environment before printing this 
email.*

-- 
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] Correct way to bump a Go library to v2

[Alex Efros]

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 both version in master.

There is an option to use gopkg.in to get alternate import path for v1.
This way users of go+v1 will have to rewrite import path to gopkg.in's,
but this let you keep v1 code only in v1 branch and remove it from master.

My opinion - no matter how promising vgo is, it's too early to give up on
go support. :) So, real question is not "to support go or not", but is "to
support v1 or not".

If your answer is "not", then feel free to remove it from master and let
v1 users either vendor it or rewrite import to gopkg.in. Moreover, in this
case you can avoid creating (arguably ugly) v2 directory - vgo should be
able to correctly handle v2 in repo root and use /v2 import path, while go
will continue using old (arguably wrong, but that's how everything works
now for most of packages anyway, and it will be fixed more of less
automatically when vgo will be released as go) import path.

-- 
WBR, Alex.

-- 
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] Correct way to bump a Go library to v2

[Nick Snyder]

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 project and then a go.mod in the v2 folder with contents 
like `module "github.com/nicksnyder/foo/v2"`

For (3) though, I am a little hesitant to delete the v1 code from master 
since this will break people go getting v1. Should I just leave it there 
for now? Should I not worry about this as a library author and expect 
consumers to be appropriately versioning/vendoring their dependency on my 
library?

-- 
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] Did you try to handle http gzip requests?

[andrey mirtchovski]

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, Yaroslav Molochko  wrote:
> 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)
>
> if the reader is gzip.Reader - it throws an error: "unexpected EOF"
>
>
>
> On Thu, Apr 12, 2018 at 10:45 PM andrey mirtchovski 
> wrote:
>>
>> 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 the
>> function call refer to this article and the articles it links to:
>>
>> https://joeshaw.org/understanding-go-panic-output/
>>
>> The cause for this is due to the gzip library attempting to read a
>> header from the reader before fully creating it. If it fails it may
>> return io.EOF, as described in this comment:
>>
>> https://golang.org/src/compress/gzip/gunzip.go?#L180
>>
>> which will be propagated up to your handler and will cause the error
>> checking to fail.
>>
>> your best source of action, in my opinion, is to treat io.EOF from
>> gzip.NewReader() as a real error.
>>
>> On Thu, Apr 12, 2018 at 1:09 PM, Yaroslav Molochko 
>> wrote:
>> > 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())
>> > }
>> > defer gz.Close()
>> > reader = gz
>> > case "deflate":
>> > def := flate.NewReader(r.Body)
>> > defer def.Close()
>> > reader = def
>> > default:
>> > // just use the default reader
>> > reader = r.Body
>> > }
>> > body, err := ioutil.ReadAll(reader)
>> > fmt.Println(string(body))
>> > }
>> >
>> > non gzip requests are passing by, but gzip is always falling with panic:
>> > 19:46:09.058697 server.go:2923: http: panic serving 127.0.0.1:63744:
>> > runtime
>> > error: invalid memory address or nil pointer dereference
>> > goroutine 29 [running]:
>> > net/http.(*conn).serve.func1(0xc4200b5ae0)
>> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1726
>> > +0xd0
>> > panic(0x13fe840, 0x16cfc60)
>> > /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505
>> > +0x229
>> > compress/gzip.(*Reader).Close(0x0, 0x1a, 0xc420069cb0)
>> >
>> > /usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:292
>> > +0x22
>> > panic(0x13fe840, 0x16cfc60)
>> > /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505
>> > +0x229
>> > io/ioutil.readAll.func1(0xc420069c00)
>> > /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:30
>> > +0x104
>> > panic(0x13fe840, 0x16cfc60)
>> > /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505
>> > +0x229
>> > compress/gzip.(*Reader).Read(0x0, 0xc420204200, 0x200, 0x200, 0x200,
>> > 0x200,
>> > 0xc420204200)
>> >
>> > /usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:247
>> > +0x37
>> > bytes.(*Buffer).ReadFrom(0xc4201b78f0, 0x14ce020, 0x0, 0xc4201740a0,
>> > 0xc420069c10, 0x10d0211)
>> > /usr/local/Cellar/go/1.10/libexec/src/bytes/buffer.go:205 +0xa0
>> > io/ioutil.readAll(0x14ce020, 0x0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
>> > /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:36
>> > +0xb5
>> > io/ioutil.ReadAll(0x14ce020, 0x0, 0x0, 0x1a, 0xc420069cb0, 0x1, 0x1)
>> > /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:45
>> > +0x3e
>> > main.handler(0x14d25c0, 0xc420202380, 0xc42013e200)
>> >
>> > /Users/onorua/dev/go/src/github.com/onorua/gpr-edge/gpr-edge.go:83
>> > +0xe0
>> > net/http.HandlerFunc.ServeHTTP(0x149a500, 0x14d25c0, 0xc420202380,
>> > 0xc42013e200)
>> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1947
>> > +0x44
>> > net/http.(*ServeMux).ServeHTTP(0x16df780, 0x14d25c0, 0xc420202380,
>> > 0xc42013e200)
>> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2337
>> > +0x130
>> > net/http.serverHandler.ServeHTTP(0xc42009d860, 0x14d25c0, 0xc420202380,
>> > 0xc42013e200)
>> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2694
>> > +0xbc
>> > net/http.(*conn).serve(0xc4200b5ae0, 0x14d2b40, 0xc42019ea00)
>> > 

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

[Yaroslav Molochko]

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)

if the reader is gzip.Reader - it throws an error: "unexpected EOF"



On Thu, Apr 12, 2018 at 10:45 PM andrey mirtchovski 
wrote:

> 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 the
> function call refer to this article and the articles it links to:
>
> https://joeshaw.org/understanding-go-panic-output/
>
> The cause for this is due to the gzip library attempting to read a
> header from the reader before fully creating it. If it fails it may
> return io.EOF, as described in this comment:
>
> https://golang.org/src/compress/gzip/gunzip.go?#L180
>
> which will be propagated up to your handler and will cause the error
> checking to fail.
>
> your best source of action, in my opinion, is to treat io.EOF from
> gzip.NewReader() as a real error.
>
> On Thu, Apr 12, 2018 at 1:09 PM, Yaroslav Molochko 
> wrote:
> > 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())
> > }
> > defer gz.Close()
> > reader = gz
> > case "deflate":
> > def := flate.NewReader(r.Body)
> > defer def.Close()
> > reader = def
> > default:
> > // just use the default reader
> > reader = r.Body
> > }
> > body, err := ioutil.ReadAll(reader)
> > fmt.Println(string(body))
> > }
> >
> > non gzip requests are passing by, but gzip is always falling with panic:
> > 19:46:09.058697 server.go:2923: http: panic serving 127.0.0.1:63744:
> runtime
> > error: invalid memory address or nil pointer dereference
> > goroutine 29 [running]:
> > net/http.(*conn).serve.func1(0xc4200b5ae0)
> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1726
> +0xd0
> > panic(0x13fe840, 0x16cfc60)
> > /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
> > compress/gzip.(*Reader).Close(0x0, 0x1a, 0xc420069cb0)
> > /usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:292
> > +0x22
> > panic(0x13fe840, 0x16cfc60)
> > /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
> > io/ioutil.readAll.func1(0xc420069c00)
> > /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:30
> +0x104
> > panic(0x13fe840, 0x16cfc60)
> > /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
> > compress/gzip.(*Reader).Read(0x0, 0xc420204200, 0x200, 0x200, 0x200,
> 0x200,
> > 0xc420204200)
> > /usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:247
> > +0x37
> > bytes.(*Buffer).ReadFrom(0xc4201b78f0, 0x14ce020, 0x0, 0xc4201740a0,
> > 0xc420069c10, 0x10d0211)
> > /usr/local/Cellar/go/1.10/libexec/src/bytes/buffer.go:205 +0xa0
> > io/ioutil.readAll(0x14ce020, 0x0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
> > /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:36
> +0xb5
> > io/ioutil.ReadAll(0x14ce020, 0x0, 0x0, 0x1a, 0xc420069cb0, 0x1, 0x1)
> > /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:45
> +0x3e
> > main.handler(0x14d25c0, 0xc420202380, 0xc42013e200)
> > /Users/onorua/dev/go/src/
> github.com/onorua/gpr-edge/gpr-edge.go:83
> > +0xe0
> > net/http.HandlerFunc.ServeHTTP(0x149a500, 0x14d25c0, 0xc420202380,
> > 0xc42013e200)
> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1947
> +0x44
> > net/http.(*ServeMux).ServeHTTP(0x16df780, 0x14d25c0, 0xc420202380,
> > 0xc42013e200)
> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2337
> +0x130
> > net/http.serverHandler.ServeHTTP(0xc42009d860, 0x14d25c0, 0xc420202380,
> > 0xc42013e200)
> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2694
> +0xbc
> > net/http.(*conn).serve(0xc4200b5ae0, 0x14d2b40, 0xc42019ea00)
> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1830
> +0x651
> > created by net/http.(*Server).Serve
> > /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2795
> +0x27b
> > what am I doing wrong?
> >
> > --
> > 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] Did you try to handle http gzip requests?

[andrey mirtchovski]

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 the
function call refer to this article and the articles it links to:

https://joeshaw.org/understanding-go-panic-output/

The cause for this is due to the gzip library attempting to read a
header from the reader before fully creating it. If it fails it may
return io.EOF, as described in this comment:

https://golang.org/src/compress/gzip/gunzip.go?#L180

which will be propagated up to your handler and will cause the error
checking to fail.

your best source of action, in my opinion, is to treat io.EOF from
gzip.NewReader() as a real error.

On Thu, Apr 12, 2018 at 1:09 PM, Yaroslav Molochko  wrote:
> 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())
> }
> defer gz.Close()
> reader = gz
> case "deflate":
> def := flate.NewReader(r.Body)
> defer def.Close()
> reader = def
> default:
> // just use the default reader
> reader = r.Body
> }
> body, err := ioutil.ReadAll(reader)
> fmt.Println(string(body))
> }
>
> non gzip requests are passing by, but gzip is always falling with panic:
> 19:46:09.058697 server.go:2923: http: panic serving 127.0.0.1:63744: runtime
> error: invalid memory address or nil pointer dereference
> goroutine 29 [running]:
> net/http.(*conn).serve.func1(0xc4200b5ae0)
> /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1726 +0xd0
> panic(0x13fe840, 0x16cfc60)
> /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
> compress/gzip.(*Reader).Close(0x0, 0x1a, 0xc420069cb0)
> /usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:292
> +0x22
> panic(0x13fe840, 0x16cfc60)
> /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
> io/ioutil.readAll.func1(0xc420069c00)
> /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:30 +0x104
> panic(0x13fe840, 0x16cfc60)
> /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
> compress/gzip.(*Reader).Read(0x0, 0xc420204200, 0x200, 0x200, 0x200, 0x200,
> 0xc420204200)
> /usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:247
> +0x37
> bytes.(*Buffer).ReadFrom(0xc4201b78f0, 0x14ce020, 0x0, 0xc4201740a0,
> 0xc420069c10, 0x10d0211)
> /usr/local/Cellar/go/1.10/libexec/src/bytes/buffer.go:205 +0xa0
> io/ioutil.readAll(0x14ce020, 0x0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
> /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:36 +0xb5
> io/ioutil.ReadAll(0x14ce020, 0x0, 0x0, 0x1a, 0xc420069cb0, 0x1, 0x1)
> /usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:45 +0x3e
> main.handler(0x14d25c0, 0xc420202380, 0xc42013e200)
> /Users/onorua/dev/go/src/github.com/onorua/gpr-edge/gpr-edge.go:83
> +0xe0
> net/http.HandlerFunc.ServeHTTP(0x149a500, 0x14d25c0, 0xc420202380,
> 0xc42013e200)
> /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1947 +0x44
> net/http.(*ServeMux).ServeHTTP(0x16df780, 0x14d25c0, 0xc420202380,
> 0xc42013e200)
> /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2337 +0x130
> net/http.serverHandler.ServeHTTP(0xc42009d860, 0x14d25c0, 0xc420202380,
> 0xc42013e200)
> /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2694 +0xbc
> net/http.(*conn).serve(0xc4200b5ae0, 0x14d2b40, 0xc42019ea00)
> /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1830 +0x651
> created by net/http.(*Server).Serve
> /usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2795 +0x27b
> what am I doing wrong?
>
> --
> 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] Did you try to handle http gzip requests?

[Yaroslav Molochko]

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())
}
defer gz.Close()
reader = gz
case "deflate":
def := flate.NewReader(r.Body)
defer def.Close()
reader = def
default:
// just use the default reader
reader = r.Body
}
body, err := ioutil.ReadAll(reader)
fmt.Println(string(body))
}

non gzip requests are passing by, but gzip is always falling with panic:
19:46:09.058697 server.go:2923: http: panic serving 127.0.0.1:63744: 
runtime error: invalid memory address or nil pointer dereference
goroutine 29 [running]:
net/http.(*conn).serve.func1(0xc4200b5ae0)
/usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1726 +0xd0
panic(0x13fe840, 0x16cfc60)
/usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
compress/gzip.(*Reader).Close(0x0, 0x1a, 0xc420069cb0)
/usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:292 
+0x22
panic(0x13fe840, 0x16cfc60)
/usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
io/ioutil.readAll.func1(0xc420069c00)
/usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:30 +0x104
panic(0x13fe840, 0x16cfc60)
/usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
compress/gzip.(*Reader).Read(0x0, 0xc420204200, 0x200, 0x200, 0x200, 0x200, 
0xc420204200)
/usr/local/Cellar/go/1.10/libexec/src/compress/gzip/gunzip.go:247 
+0x37
bytes.(*Buffer).ReadFrom(0xc4201b78f0, 0x14ce020, 0x0, 0xc4201740a0, 
0xc420069c10, 0x10d0211)
/usr/local/Cellar/go/1.10/libexec/src/bytes/buffer.go:205 +0xa0
io/ioutil.readAll(0x14ce020, 0x0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:36 +0xb5
io/ioutil.ReadAll(0x14ce020, 0x0, 0x0, 0x1a, 0xc420069cb0, 0x1, 0x1)
/usr/local/Cellar/go/1.10/libexec/src/io/ioutil/ioutil.go:45 +0x3e
main.handler(0x14d25c0, 0xc420202380, 0xc42013e200)
/Users/onorua/dev/go/src/github.com/onorua/gpr-edge/gpr-edge.go:83 
+0xe0
net/http.HandlerFunc.ServeHTTP(0x149a500, 0x14d25c0, 0xc420202380, 
0xc42013e200)
/usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1947 +0x44
net/http.(*ServeMux).ServeHTTP(0x16df780, 0x14d25c0, 0xc420202380, 
0xc42013e200)
/usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2337 +0x130
net/http.serverHandler.ServeHTTP(0xc42009d860, 0x14d25c0, 0xc420202380, 
0xc42013e200)
/usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2694 +0xbc
net/http.(*conn).serve(0xc4200b5ae0, 0x14d2b40, 0xc42019ea00)
/usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:1830 +0x651
created by net/http.(*Server).Serve
/usr/local/Cellar/go/1.10/libexec/src/net/http/server.go:2795 +0x27b
what am I doing wrong? 

-- 
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] issue ? httptest failed to bind newly released port

[leslie . qiwa]

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 port, or app 
should avoid this behavior? Welcome to hear your thought. Thanks!

Best Regards
Leslie


-- 
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] Why does the Response Writer of the http package declare Write rather than embedding io.Writer?

[Ian Lance Taylor]

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 "Write([]byte)(int,error)" of ResponseWriter has a
> broader meaning so that many other "String() string" declarations do not
> embed fmt.Stringer.
>
> Why does not http.ResponseWriter embed io.Writer?
> I think that the reason will help us understand the interface of Golang more
> deeply.

I don't think there was any special reason.  The end result is exactly
the same whether the interface says `io.Writer` or `Write([]byte)
(int, error)`.  Using an explicit Write method is only slightly
longer, and is, if anything, more clear.

Ian

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[peter . aba . zsolt]

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 is to save money on some prototype project. You want to test if 
your blog will catch on or if you can sell your shiny-product online? Sure 
use some existing PHP project (Magento, Wordpress, Drupal, etc.), hire some 
affordable PHP guy or team and you're good to go. (no pun intended) When it 
comes to building a new system to scale, there's nothing on the pro side 
for PHP other than somewhat cheaper devs of course. I'm saying that with 
about 15 years of PHP experience and having worked on non-trivial 
applications.

On Thursday, 5 April 2018 19:26:19 UTC+2, bingj...@gmail.com wrote:
>
> Almost 10 years golang appears in the world. 10 years is not a short 
> duration. I think if it is not popular until 2020, it will never be popular.
>
> Golang is designed for cloud and internet areas. Really?
>
> The creators of golang have a lot of experience in C and C++. And golang 
> borrows features from C and C++. But C and C++ do not fit the requirements 
> of cloud and internet areas.
>
> Let's look at two popular programming languages java and php. What is the 
> most important features of these two languages? Simple, ugly but 
> practical... I find one feather: they are both not just programming 
> languages but also platforms. They are almost the same in Windows and 
> Linux. That's why java and php are very popular in recent days.
>
> C and C++ are just pure programming languages, not platforms. On Unix and 
> Windows, C and C++ are very different. A developer of windows C++ is not a 
> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>
> If golang wants to be widely used by developer all over the world before 
> 2020, it must learn some thing from java and php, must be a 
> programming-language-is-a-platform.
>
> Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.
>
> Yes, Golang is very like C and C++, which are only pure programming 
> language, But this times, we need "language as/is platform" technologies, 
> just like php and java.
>
> I have watched golang for many years, but never turn to it. Why? I think 
> it is still semi-finished product. Creators of golang are researchers, not 
> engineers, they worked too slow.
>

-- 
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] Why does the Response Writer of the http package declare Write rather than embedding io.Writer?

[bonpi bonpi]

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 meaning so that many other "String() string" declarations do not 
embed fmt.Stringer.

Why does not http.ResponseWriter embed io.Writer?
I think that the reason will help us understand the interface of Golang 
more deeply.

Thanks.

-- 
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/http: go server requires to read the entire request body before writing response

[Berk S.]

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.org/p/G8F0X4DQCDn

There seems to be a one-liner fix but is there anyone that can help with this 
issue?

The discussion about this issue can be found here:

https://github.com/golang/go/issues/22209

-- 
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] omitempty by default

[Jérôme LAFORGE]

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

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

[Kaveh Shahbazian]

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 interestingly 
the exit line numbers are correct (27, 22 and 15).

-- 
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] suggestion for reader exercises throughout the go tour

[Robert P. J. Day]

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 the tour, i can see that many
of the pages do in fact have the reader test things. sorry for the
noise. back to touring ...

rday

-- 
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] suggestion for reader exercises throughout the go tour

[Robert P. J. Day]

  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 exercise would be to ask the reader to remove the last
initializer from the statement:

  var c, python, java = true, false, "no!"

to see what happens. trivially simple, and demonstrates what happens
with insufficient initializers. i suspect a lot of the tour pages
could have a simple reader exercise added to them to get the reader
involved. thoughts?

rday

-- 
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: where would one find "go tool tour" with fedora-installed pkgs?

[Robert P. J. Day]

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