Re: [go-nuts] why my program will panic?

[sheepbao]

I just want to research how golang func stack work. 

On Tuesday, August 14, 2018 at 12:46:59 PM UTC+8, kortschak wrote:
>
> Why would you expect this to work? 
>
> On Mon, 2018-08-13 at 20:44 -0700, sheepbao wrote: 
> > go version 
> > go version go1.10.2 darwin/amd64 
> > 
> > test code: 
> > 
> > func TestPoint(t *testing.T) { 
> > type A struct { 
> > X int 
> > Y string 
> > } 
> > type B struct { 
> > X int 
> > Y string 
> > Z string 
> > } 
> > 
> > a := A{X: 2, Y: "yy"} 
> > b := (*B)(unsafe.Pointer()) 
> > b.Z = "zz" 
> > 
> > fmt.Printf(" z: %v\n", b.Z) 
> > return 
> > } 
> > 
> >   
> > 
> > panic info: 
> > === RUN TestPoint 
> > z: zz 
> > runtime: unexpected return pc for runtime.sigpanic called from 0x2 
> > stack: frame={sp:0xc42004cf58, fp:0xc42004cfa8}  
> > stack=[0xc42004c000,0xc42004d000) 
> > 00c42004ce58: 00c42004ce88 010514bb 
> >   
> > 00c42004ce68: 00c4200c00f0 00c4200b8020  
> > 00c42004ce78: 0007 0020  
> > 00c42004ce88: 00c42004cf28 01027ee9 
> >   
> > 00c42004ce98:  01136758  
> > 00c42004cea8: 00c42008e6b0 00080008  
> > 00c42004ceb8:  00c420033720  
> > 00c42004cec8: 010973c2  00c420066600  
> > 00c42004ced8: 00c42009a008 00c42008e6a0  
> > 00c42004cee8: 00c42008e680 00c420066628  
> > 00c42004cef8: 00c420066620 00c42004ce68  
> > 00c42004cf08: 01108ea0 011d4f80  
> > 00c42004cf18:  0001  
> > 00c42004cf28: 00c42004cf48 01026f5e 
> >   
> > 00c42004cf38: 01108ea0 011d4f80  
> > 00c42004cf48: 00c42004cf98 0103b7aa 
> >   
> > 00c42004cf58: <00c420066600 0001  
> > 00c42004cf68:  010fe240  
> > 00c42004cf78: 00c420082460 00c420066600  
> > 00c42004cf88: 0112d8f6 0002  
> > 00c42004cf98: 0112d8f8 !0002  
> > 00c42004cfa8: >00c4200c00f0 000aace2  
> > 00c42004cfb8: 011dc160   
> > 00c42004cfc8: 01053ac1  
> > 00c4200c00f0  
> > 00c42004cfd8: 01136150   
> > 00c42004cfe8:    
> > 00c42004cff8:   
> > fatal error: unknown caller pc 
> > 
> > runtime stack: 
> > runtime.throw(0x112fd13, 0x11) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go 
> > :616  
> > +0x81 
> > runtime.gentraceback(0x, 0x, 0x0,  
> > 0xc420066600, 0x0, 0x0, 0x7fff, 0x1136348, 0x7ffeefbff088, 0x0, 
> > ...) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/tracebac 
> > k.go:257  
> > +0x1bdb 
> > runtime.copystack(0xc420066600, 0x1000, 0x1) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/stack.go 
> > :891  
> > +0x270 
> > runtime.newstack() 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/stack.go 
> > :1063  
> > +0x30f 
> > runtime.morestack() 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/asm_amd6 
> > 4.s:492  
> > +0x89 
> > 
> > goroutine 19 [copystack]: 
> > fmt.(*pp).argNumber(0xc4200c6000, 0x0, 0x112db26, 0x5, 0x1, 0x1, 0x0, 
> > 0x0,  
> > 0x0) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:926 
> >   
> > +0x112 fp=0xc42004cb48 sp=0xc42004cb40 pc=0x109d9a2 
> > fmt.(*pp).doPrintf(0xc4200c6000, 0x112db26, 0x5, 0xc42004ccc8, 0x1, 
> > 0x1) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:101 
> > 4  
> > +0x1ca fp=0xc42004cc30 sp=0xc42004cb48 pc=0x109deba 
> > fmt.Sprintf(0x112db26, 0x5, 0xc4200334c8, 0x1, 0x1, 0xc42008e6d8,  
> > 0xc42008e6e0) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:203 
> > +0x66  
> > fp=0xc42004cc88 sp=0xc42004cc30 pc=0x1097466 
> > testing.fmtDuration(0xa388, 0x3, 0xc420026570) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing. 
> > go:438  
> > +0xdf fp=0xc42004cce8 sp=0xc42004cc88 pc=0x10ae90f 
> > testing.(*T).report(0xc4200c00f0) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing. 
> > go:997  
> > +0x57 fp=0xc42004cdf8 sp=0xc42004cce8 pc=0x10afcf7 
> > testing.tRunner.func1(0xc4200c00f0) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing. 
> > go:741  
> > +0x285 fp=0xc42004ce68 sp=0xc42004cdf8 pc=0x10b2e75 
> > runtime.call32(0x0, 0x1136758, 0xc42008e6b0, 0x80008) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/asm_amd6 
> > 4.s:585  
> > +0x3b fp=0xc42004ce98 sp=0xc42004ce68 pc=0x10514bb 
> > panic(0x1108ea0, 0x11d4f80) 
> > /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go 
> > :502  
> > +0x229 fp=0xc42004cf38 sp=0xc42004ce98 

[go-nuts] AWS S3 Image Upload with Golang

[maksach]

Hi,

I am trying to upload a local image file to an AWS S3 bucket and return the 
public URL in Golang. This is the core Golang code I have written to 
interact with my S3 bucket:

creds := 
credentials.NewSharedCredentials("/Users/username/.aws/credentials", 
"default")

config := {
Region:  aws.String("us-west-2"),
Credentials: creds,
}

sess := session.New(config)

uploader := s3manager.NewUploader(sess, func(u *s3manager.Uploader) {
u.PartSize = 64 * 1024 * 1024 
u.LeavePartsOnError = true
})

fmt.Println(header.Filename)

fileInfo, _ := out.Stat()
var size int64 =  fileInfo.Size()
fmt.Println("size", size)
buffer := make([]byte, size) 

out.Read(buffer)
fileBytes := bytes.NewReader(buffer)

result, err := uploader.Upload({
Bucket: aws.String("bucket-name"),
Key: aws.String(header.Filename),
Body: aws.ReadSeekCloser(fileBytes),
ContentType: aws.String("image/jpeg"),
ACL: aws.String("public-read"),
})
if err != nil || result == nil {
log.Fatalln("Failed to upload", err)
}

log.Println("Successfully uploaded to", result.Location)

With this code, the file is uploaded successfully to my s3 bucket with the 
correct size in bytes, but when I click on the URL, a black square is 
displayed instead of the actual image. If I change the ContentType field to 
allow file types dynamically, when I click on the URL, it downloads the 
image, but the image cannot be opened because "it may have been damaged." 
How can I fix this Golang code to just upload an image to an S3 bucket and 
get the public URL as a result of that upload?

This may be more of a debugging question pertaining to AWS S3 than Golang, 
but any help would be appreciated. Thank you!

-- 
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: Compile to go languages?

[Andrey Tcherepanov]

There are projects by cznic on github to convert C code to Go in different 
stages of progress

https://github.com/cznic/ccgo
https://github.com/cznic/sqlite2go
https://github.com/cznic/crt

There are some other projects by him (parsing related projects) that you 
might find interesting.

A.


On Monday, August 13, 2018 at 4:48:59 PM UTC-6, Andrew Chambers wrote:
>
> Don't get me wrong, I love go, but also wonder if there are any languages 
> that compile to idiomatic go.
> I noticed reasonml compiles to javascript, and wondered to myself if there 
> is any value in such languages using go as a base for 
> interop to take advantage of the libraries and runtime.
>
> Any existing projects? Any thoughts about why its a good or bad idea, or 
> why it doesn't seem to exist already?
>

-- 
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 my program will panic?

[Dan Kortschak]

Why would you expect this to work?

On Mon, 2018-08-13 at 20:44 -0700, sheepbao wrote:
> go version
> go version go1.10.2 darwin/amd64
> 
> test code:
> 
> func TestPoint(t *testing.T) {
> type A struct {
> X int
> Y string
> }
> type B struct {
> X int
> Y string
> Z string
> }
> 
> a := A{X: 2, Y: "yy"}
> b := (*B)(unsafe.Pointer())
> b.Z = "zz"
> 
> fmt.Printf(" z: %v\n", b.Z)
> return
> }
> 
>  
> 
> panic info:
> === RUN TestPoint
> z: zz
> runtime: unexpected return pc for runtime.sigpanic called from 0x2
> stack: frame={sp:0xc42004cf58, fp:0xc42004cfa8} 
> stack=[0xc42004c000,0xc42004d000)
> 00c42004ce58: 00c42004ce88 010514bb
>  
> 00c42004ce68: 00c4200c00f0 00c4200b8020 
> 00c42004ce78: 0007 0020 
> 00c42004ce88: 00c42004cf28 01027ee9
>  
> 00c42004ce98:  01136758 
> 00c42004cea8: 00c42008e6b0 00080008 
> 00c42004ceb8:  00c420033720 
> 00c42004cec8: 010973c2  00c420066600 
> 00c42004ced8: 00c42009a008 00c42008e6a0 
> 00c42004cee8: 00c42008e680 00c420066628 
> 00c42004cef8: 00c420066620 00c42004ce68 
> 00c42004cf08: 01108ea0 011d4f80 
> 00c42004cf18:  0001 
> 00c42004cf28: 00c42004cf48 01026f5e
>  
> 00c42004cf38: 01108ea0 011d4f80 
> 00c42004cf48: 00c42004cf98 0103b7aa
>  
> 00c42004cf58: <00c420066600 0001 
> 00c42004cf68:  010fe240 
> 00c42004cf78: 00c420082460 00c420066600 
> 00c42004cf88: 0112d8f6 0002 
> 00c42004cf98: 0112d8f8 !0002 
> 00c42004cfa8: >00c4200c00f0 000aace2 
> 00c42004cfb8: 011dc160  
> 00c42004cfc8: 01053ac1 
> 00c4200c00f0 
> 00c42004cfd8: 01136150  
> 00c42004cfe8:   
> 00c42004cff8:  
> fatal error: unknown caller pc
> 
> runtime stack:
> runtime.throw(0x112fd13, 0x11)
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go
> :616 
> +0x81
> runtime.gentraceback(0x, 0x, 0x0, 
> 0xc420066600, 0x0, 0x0, 0x7fff, 0x1136348, 0x7ffeefbff088, 0x0,
> ...)
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/tracebac
> k.go:257 
> +0x1bdb
> runtime.copystack(0xc420066600, 0x1000, 0x1)
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/stack.go
> :891 
> +0x270
> runtime.newstack()
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/stack.go
> :1063 
> +0x30f
> runtime.morestack()
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/asm_amd6
> 4.s:492 
> +0x89
> 
> goroutine 19 [copystack]:
> fmt.(*pp).argNumber(0xc4200c6000, 0x0, 0x112db26, 0x5, 0x1, 0x1, 0x0,
> 0x0, 
> 0x0)
> /Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:926
>  
> +0x112 fp=0xc42004cb48 sp=0xc42004cb40 pc=0x109d9a2
> fmt.(*pp).doPrintf(0xc4200c6000, 0x112db26, 0x5, 0xc42004ccc8, 0x1,
> 0x1)
> /Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:101
> 4 
> +0x1ca fp=0xc42004cc30 sp=0xc42004cb48 pc=0x109deba
> fmt.Sprintf(0x112db26, 0x5, 0xc4200334c8, 0x1, 0x1, 0xc42008e6d8, 
> 0xc42008e6e0)
> /Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:203
> +0x66 
> fp=0xc42004cc88 sp=0xc42004cc30 pc=0x1097466
> testing.fmtDuration(0xa388, 0x3, 0xc420026570)
> /Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing.
> go:438 
> +0xdf fp=0xc42004cce8 sp=0xc42004cc88 pc=0x10ae90f
> testing.(*T).report(0xc4200c00f0)
> /Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing.
> go:997 
> +0x57 fp=0xc42004cdf8 sp=0xc42004cce8 pc=0x10afcf7
> testing.tRunner.func1(0xc4200c00f0)
> /Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing.
> go:741 
> +0x285 fp=0xc42004ce68 sp=0xc42004cdf8 pc=0x10b2e75
> runtime.call32(0x0, 0x1136758, 0xc42008e6b0, 0x80008)
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/asm_amd6
> 4.s:585 
> +0x3b fp=0xc42004ce98 sp=0xc42004ce68 pc=0x10514bb
> panic(0x1108ea0, 0x11d4f80)
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go
> :502 
> +0x229 fp=0xc42004cf38 sp=0xc42004ce98 pc=0x1027ee9
> runtime.panicmem()
> /Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go
> :63 
> +0x5e fp=0xc42004cf58 sp=0xc42004cf38 pc=0x1026f5e
> runtime: unexpected return pc for runtime.sigpanic called from 0x2
> stack: frame={sp:0xc42004cf58, fp:0xc42004cfa8} 
> stack=[0xc42004c000,0xc42004d000)
> 00c42004ce58: 00c42004ce88 010514bb
>  
> 00c42004ce68: 00c4200c00f0 00c4200b8020 
> 00c42004ce78: 0007 0020 
> 00c42004ce88: 

[go-nuts] Re: why my program will panic?

[sheepbao]

and I change one line code, than program does not panic.


func TestPoint(t *testing.T) {
type A struct {
X int
Y string
}
type B struct {
X int
Y string
Z string
}

a := A{X: 2, Y: "yy"}
b := (*B)(unsafe.Pointer())
b.Z = "zz"

// fmt.Printf(" z: %v\n", b.Z)
fmt.Printf(" z: %v\n", ) // a move to heap
return
} 


-- 
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 my program will panic?

[sheepbao]

go version
go version go1.10.2 darwin/amd64

test code:

func TestPoint(t *testing.T) {
type A struct {
X int
Y string
}
type B struct {
X int
Y string
Z string
}

a := A{X: 2, Y: "yy"}
b := (*B)(unsafe.Pointer())
b.Z = "zz"

fmt.Printf(" z: %v\n", b.Z)
return
}

 

panic info:
=== RUN TestPoint
z: zz
runtime: unexpected return pc for runtime.sigpanic called from 0x2
stack: frame={sp:0xc42004cf58, fp:0xc42004cfa8} 
stack=[0xc42004c000,0xc42004d000)
00c42004ce58: 00c42004ce88 010514bb  
00c42004ce68: 00c4200c00f0 00c4200b8020 
00c42004ce78: 0007 0020 
00c42004ce88: 00c42004cf28 01027ee9  
00c42004ce98:  01136758 
00c42004cea8: 00c42008e6b0 00080008 
00c42004ceb8:  00c420033720 
00c42004cec8: 010973c2  00c420066600 
00c42004ced8: 00c42009a008 00c42008e6a0 
00c42004cee8: 00c42008e680 00c420066628 
00c42004cef8: 00c420066620 00c42004ce68 
00c42004cf08: 01108ea0 011d4f80 
00c42004cf18:  0001 
00c42004cf28: 00c42004cf48 01026f5e  
00c42004cf38: 01108ea0 011d4f80 
00c42004cf48: 00c42004cf98 0103b7aa  
00c42004cf58: <00c420066600 0001 
00c42004cf68:  010fe240 
00c42004cf78: 00c420082460 00c420066600 
00c42004cf88: 0112d8f6 0002 
00c42004cf98: 0112d8f8 !0002 
00c42004cfa8: >00c4200c00f0 000aace2 
00c42004cfb8: 011dc160  
00c42004cfc8: 01053ac1  00c4200c00f0 
00c42004cfd8: 01136150  
00c42004cfe8:   
00c42004cff8:  
fatal error: unknown caller pc

runtime stack:
runtime.throw(0x112fd13, 0x11)
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go:616 
+0x81
runtime.gentraceback(0x, 0x, 0x0, 
0xc420066600, 0x0, 0x0, 0x7fff, 0x1136348, 0x7ffeefbff088, 0x0, ...)
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/traceback.go:257 
+0x1bdb
runtime.copystack(0xc420066600, 0x1000, 0x1)
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/stack.go:891 
+0x270
runtime.newstack()
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/stack.go:1063 
+0x30f
runtime.morestack()
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/asm_amd64.s:492 
+0x89

goroutine 19 [copystack]:
fmt.(*pp).argNumber(0xc4200c6000, 0x0, 0x112db26, 0x5, 0x1, 0x1, 0x0, 0x0, 
0x0)
/Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:926 
+0x112 fp=0xc42004cb48 sp=0xc42004cb40 pc=0x109d9a2
fmt.(*pp).doPrintf(0xc4200c6000, 0x112db26, 0x5, 0xc42004ccc8, 0x1, 0x1)
/Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:1014 
+0x1ca fp=0xc42004cc30 sp=0xc42004cb48 pc=0x109deba
fmt.Sprintf(0x112db26, 0x5, 0xc4200334c8, 0x1, 0x1, 0xc42008e6d8, 
0xc42008e6e0)
/Users/bao/Documents/reading/golang/go1.10.2/src/fmt/print.go:203 +0x66 
fp=0xc42004cc88 sp=0xc42004cc30 pc=0x1097466
testing.fmtDuration(0xa388, 0x3, 0xc420026570)
/Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing.go:438 
+0xdf fp=0xc42004cce8 sp=0xc42004cc88 pc=0x10ae90f
testing.(*T).report(0xc4200c00f0)
/Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing.go:997 
+0x57 fp=0xc42004cdf8 sp=0xc42004cce8 pc=0x10afcf7
testing.tRunner.func1(0xc4200c00f0)
/Users/bao/Documents/reading/golang/go1.10.2/src/testing/testing.go:741 
+0x285 fp=0xc42004ce68 sp=0xc42004cdf8 pc=0x10b2e75
runtime.call32(0x0, 0x1136758, 0xc42008e6b0, 0x80008)
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/asm_amd64.s:585 
+0x3b fp=0xc42004ce98 sp=0xc42004ce68 pc=0x10514bb
panic(0x1108ea0, 0x11d4f80)
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go:502 
+0x229 fp=0xc42004cf38 sp=0xc42004ce98 pc=0x1027ee9
runtime.panicmem()
/Users/bao/Documents/reading/golang/go1.10.2/src/runtime/panic.go:63 
+0x5e fp=0xc42004cf58 sp=0xc42004cf38 pc=0x1026f5e
runtime: unexpected return pc for runtime.sigpanic called from 0x2
stack: frame={sp:0xc42004cf58, fp:0xc42004cfa8} 
stack=[0xc42004c000,0xc42004d000)
00c42004ce58: 00c42004ce88 010514bb  
00c42004ce68: 00c4200c00f0 00c4200b8020 
00c42004ce78: 0007 0020 
00c42004ce88: 00c42004cf28 01027ee9  
00c42004ce98:  01136758 
00c42004cea8: 00c42008e6b0 00080008 
00c42004ceb8:  00c420033720 
00c42004cec8: 010973c2  00c420066600 
00c42004ced8: 00c42009a008 00c42008e6a0 
00c42004cee8: 00c42008e680 00c420066628 
00c42004cef8: 

[go-nuts] Re: Keep Vendor folder on library Repository is Bad or Good practice.

[mart]

On Saturday, July 28, 2018 at 11:43:04 AM UTC-7, nafis wrote:
>
> Suppose I'm making a library and it does reference some other library not 
> part of the standard library. I want to vendor those so that my library 
> doesn't fail if the other 3rd party developer deletes their library or 
> major changes of their library(I know this sound like stupid design). And I 
> want to push the vendor folder on my library repo. My question: Is this 
> the bad idea keep a vendor folder on the library repo.
>
> Thank you for your time.
>

There are some practical considerations to vendoring within a library:

1. If any types from a vendored package appear in the exported interface of 
your library, no caller will be able to write down the full names of those 
types because their imports are not from your vendored package path, and so 
your library may be difficult to use.

2. If the package you are vendoring does anything that relies on the full 
resolved package path at runtime -- for example, gob encoding uses it by 
default via reflection when registering types -- then the copy in your 
vendor directory will see the vendor package path, which may cause problems 
if the resulting value leaves your program and must be consumed by another 
program that was expecting the "canonical" path.

I believe if neither of these are true for your library then the decision 
is entirely internal to your library and callers will not be able to 
observe any difference compared to a non-vendored copy of the same 
dependency.


-- 
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: Keep Vendor folder on library Repository is Bad or Good practice.

[Dan Kortschak]

It is still there because someone if (hopefully) benificently name
squatting there with the same package. It went away and broke things.
The person who owns jteeuwen is not Jim (the original owner), and has
put back the go-bindata repo to avoid a breakage. It could be far
worse.

On Mon, 2018-08-13 at 11:17 -0400, Tong Sun wrote:
> I have no idea what's going on there or the history, but I see
> https://github.com/jteeuwen/go-bindata is still there, despite that
> "this
> repository is not maintained".

-- 
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] liteide x34.1 released, support go1.11 modules

[Space A.]

Thank you for your great work!



понедельник, 13 августа 2018 г., 18:01:22 UTC+3 пользователь visualfc 
написал:
>
> Hi, all.
> LiteIDE X34.1 released!
> This version update gocode to support go1.11 modules and vendor by source 
> parser.
>
> * LiteIDE Home
> 
> * LiteIDE Source code
> 
> * Release downloads
> * 
> * 
>
> ### 2018.08.12 Ver X34.1
>
> * LiteIDE
>
>   * update gotools support go1.11 modules
>
>   * update gocode support go1.11 modules and vendor
>
> * LiteEditor
>
>   * enable open binary file for editor
>
>   * change widget readonly by binary file (ignore text file)
>
> * gocode
>
>   * change parser by source use gotools/types
>
>   * fix parser vendor & modules
>
>
>
> --
> Sent from YoMail for Gmail  
>

-- 
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 test -c` skips init from main while `go test` doesn't

[Gert]

Hi, `go test` runs the main init but the binary created by 

go test -c -a -tags 'netgo noplugin' -gcflags "all=-N -l"

doesn't. Is this a bug? Also it's seems you can't compile static test 
binaries only non test binaries can be compiled static?

-- 
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] Compile to go languages?

[andrewchamberss]

Don't get me wrong, I love go, but also wonder if there are any languages 
that compile to idiomatic go.
I noticed reasonml compiles to javascript, and wondered to myself if there 
is any value in such languages using go as a base for 
interop to take advantage of the libraries and runtime.

Any existing projects? Any thoughts about why its a good or bad idea, or 
why it doesn't seem to exist already?

-- 
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: Cross-compiled program for Raspberry Pi crashes

[Dave Cheney]

I don’t think that will help. The problem is not cross compilation. The problem 
is when run in a 32bit environment the offset of that field is not guaranteed 
to be aligned to 8 bytes. You’ve got a 50/50 chance that each allocation will 
be properly aligned. 

-- 
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: Examples testing with two newline, but only one newline

[jake6502]

Looks like a bug to me. I would suggest you open an issue.

It is not clear to me what the intended behavior is. It is documented that 
examples strip some white space when comparing output. So it may be 
intentional that multiple white space lines are removed from the expected 
output. In that case, IMO, the bug is that the same transformation is not 
applied to the output before comparing. Conversely, it is possible that the 
removal of the blank lines is the bug. 

That said, since examples are documented to "strip white space", I would 
remind you to also write actual tests, if the white space of the results 
matters to you. 


On Saturday, August 11, 2018 at 4:10:04 AM UTC-4, 子風 wrote:
>
> Hi
>
> https://play.golang.org/p/AIB-yJaExVu
>
> When I want to use examples to test my code, I find something odd.
> Example1 could pass, but Example2 failed
>
> --- FAIL: Example2 (0.00s)
>> got:
>> hello
>> .
>>
>> 123
>> want:
>> hello
>> .
>> 123
>> FAIL
>> exit status 1
>
>
> It seems Examples could only show one newline.
> Is there a solution to solve it? 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.

Re: [go-nuts] Re: Cross-compiled program for Raspberry Pi crashes

[Philip Chapman]

Another option may be to run 32 bit raspberian OS and compile in a virtual
machine and compile it there, perhaps.  VirtualBox comes to mind.

On Mon, Aug 13, 2018 at 1:52 PM, Stephan Mühlstrasser <
stephan.muehlstras...@gmail.com> wrote:

>
> Am Montag, 13. August 2018 22:36:56 UTC+2 schrieb Dave Cheney:
>>
>> No, it’s not a cross compilation issue. Well, yes and no, the rpi is a 32
>> bit platform so some structures have a different size causing the offset of
>> the field to be 32 but aligned, not the required 64 bit aligned.
>>
>> The play example shows the address of the field is not aligned on a 8
>> byte boundary.
>>
>
> Ah, I didn't recognize that the number in the play example is the
> problematic address from the stack trace.
>
> Short version, move the field to the top of the structure which is
>> guaranteed to be properly aligned.
>
>
> Ok, thank you. I now realized that I would have to change structures in
> third party software, so this is probably not a reasonable approach. I will
> have to live with the fact that I have to compile on the Raspberry Pi
> itself, and I hope that the compiler bug will not manifest itself there.
>
> --
> 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.
>



-- 
Philip A. Chapman
Java Software Development
Enterprise, Web, and Desktop

-- 
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: Cross-compiled program for Raspberry Pi crashes

[Stephan Mühlstrasser]

Am Montag, 13. August 2018 22:36:56 UTC+2 schrieb Dave Cheney:
>
> No, it’s not a cross compilation issue. Well, yes and no, the rpi is a 32 
> bit platform so some structures have a different size causing the offset of 
> the field to be 32 but aligned, not the required 64 bit aligned. 
>
> The play example shows the address of the field is not aligned on a 8 byte 
> boundary. 
>

Ah, I didn't recognize that the number in the play example is the 
problematic address from the stack trace.

Short version, move the field to the top of the structure which is 
> guaranteed to be properly aligned.


Ok, thank you. I now realized that I would have to change structures in 
third party software, so this is probably not a reasonable approach. I will 
have to live with the fact that I have to compile on the Raspberry Pi 
itself, and I hope that the compiler bug will not manifest itself there.

-- 
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: Cross-compiled program for Raspberry Pi crashes

[Dave Cheney]

No, it’s not a cross compilation issue. Well, yes and no, the rpi is a 32 bit 
platform so some structures have a different size causing the offset of the 
field to be 32 but aligned, not the required 64 bit aligned. 

The play example shows the address of the field is not aligned on a 8 byte 
boundary. 

Short version, move the field to the top of the structure which is guaranteed 
to be properly aligned. 

-- 
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: HTTP/2 Adventure in the Go World

[Eyal]

Hi Michal,
Thanks,
When removed, the netconn.TestConn tests are failing for race condition 
with the -race flag.

On Monday, August 13, 2018 at 11:41:23 AM UTC+3, mic...@scylladb.com wrote:
>
> That's cool, I'm not sure if the locks on Conn object [1] are needed, 
> could it just rely on locking in http2?
>
> [1] https://github.com/posener/h2conn/blob/master/conn.go#L18
>
> On Sunday, August 12, 2018 at 4:40:03 PM UTC+2, Eyal wrote:
>>
>> Hi,
>> You are welcome to read a blog post I wrote about a short experience with 
>> HTTP/2 and Go.
>>
>> https://posener.github.io/http2/
>>
>> Cheers,
>> Eyal
>>
>

-- 
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: Cross-compiled program for Raspberry Pi crashes

[Stephan Mühlstrasser]

Am Sonntag, 12. August 2018 23:30:22 UTC+2 schrieb Dave Cheney:
>
> This is likely to be issue https://github.com/golang/go/issues/599 
> 
> , https://play.golang.org/p/zZm-6zWwFoi
>
>  
Thanks for the diagnosis, this looks like the issue I'm seeing, although I 
don't understand how the example on play.golang.org 
 is related. The example does not 
crash if I run a cross-compiled binary on the Raspberry Pi and it prints 
the correct result "false".

So do I understand it correctly that this is a bug that is exclusive to the 
cross compiler? The native compiler on the Raspberry Pi apparently is able 
to compile the code correctly?

And is it possible to work around the bug, for example by adding padding or 
by re-arranging the problematic structure?

-- 
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: Keep Vendor folder on library Repository is Bad or Good practice.

[jfbustarret]

IMHO

Don't do it for a library. Let your users decide if they prefer to commit 
their vendor directory or not.

Do whatever you want for a standalone project.

JFB

Le samedi 28 juillet 2018 20:43:04 UTC+2, nafis a écrit :
>
> Suppose I'm making a library and it does reference some other library not 
> part of the standard library. I want to vendor those so that my library 
> doesn't fail if the other 3rd party developer deletes their library or 
> major changes of their library(I know this sound like stupid design). And I 
> want to push the vendor folder on my library repo. My question: Is this 
> the bad idea keep a vendor folder on the library repo.
>
> Thank you for your time.
>

-- 
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] [ANN] Squalus, a wrapper for SQL queries

[Olivier Pérès]

Hello,

Squalus  is a small package that 
makes it easier to perform SQL queries in Go. It is a thin layer that sits 
on top of the regular Go SQL code and supported drivers (MySQL, SQLite, 
Postgres) and makes the coder’s life simple, with features such as named 
parameters, automatic expansion of slices of parameters (useful for IN 
clauses), scanning a row into a structure, scanning all rows into a slice 
or a channel, running a callback on query results. As compared to other 
similar packages, the idea is to keep writing SQL queries (it is not an 
ORM) but stop using cursors in favour of higher-level constructs.

The project is young and your feedback is welcome. Project URL: 
https://gitlab.com/qosenergy/squalus

Have a nice day,

Olivier.

-- 
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] Examples testing with two newline, but only one newline

[Shane]

Hmm I meant to reply to the group but I think I inadvertantly replied
directly (my apologies).

I'll repost my answer because I think that it may help others with the same
issue (the multi line examples!)

Hi

There are two ways to use examples with multi line outputs

1) Multi line comments (Be aware that whitespace may become an issue)

/* Output: Line1
Line 2
*/


2) Multiple single line comments (my preference)

// Output: Line1
// Line 2

HTH

On Sat, Aug 11, 2018 at 6:09 PM,  wrote:

> Hi
>
> https://play.golang.org/p/AIB-yJaExVu
>
> When I want to use examples to test my code, I find something odd.
> Example1 could pass, but Example2 failed
>
> --- FAIL: Example2 (0.00s)
>> got:
>> hello
>> .
>>
>> 123
>> want:
>> hello
>> .
>> 123
>> FAIL
>> exit status 1
>
>
> It seems Examples could only show one newline.
> Is there a solution to solve it? 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.
>

-- 
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: Keep Vendor folder on library Repository is Bad or Good practice.

[Tong Sun]

I have no idea what's going on there or the history, but I see
https://github.com/jteeuwen/go-bindata is still there, despite that "this
repository is not maintained".

On Thu, Aug 9, 2018 at 8:58 AM peterGo  wrote:

> Tong Sun
>
> "I've never seen [the Author delete the library]  happen before."
>
> It happened recently. Take a look at jteeuwen/go-bindata: Hard fork of
> jteeuwen/go-bindata because it disappeared,
>
> Peter
>
> On Wednesday, August 8, 2018 at 10:01:32 AM UTC-4, Tong Sun wrote:
>>
>> I've never seen that happen before, but in case it does, only new
>> environments will fail, i.e., those has been building fine will still be
>> building fine. I.e. it's quite easy to correct.
>>
>> So I personally think that it is really a high price to pay for something
>> that may *never* happen.
>> Of course, not everyone agree with me, as I've seen someone even worries
>> that go yaml (gopkg.in/yaml.v2) will go away someday, and insists
>> vendering it.
>>
>>
>>
>> On Wednesday, August 1, 2018 at 9:50:13 AM UTC-4, nafis wrote:
>>>
>>> How about the Author delete the library.
>>>
>>> On Tuesday, July 31, 2018 at 5:49:36 AM UTC+6, Eric Johnson wrote:

 Long term, I suspect you're better off without the vendoring.

 Specifically, I suggest looking into automating your libraries tests
 with the earliest possible versions of supported dependencies, and the
 latest versions of dependencies.

 With a tool like vgo, it should be possible to have two versions of
 your lock file that your build / test cycle can switch between. If a
 project adds backwards compatible changes, they you can test across major
 versions as well.

 Eric

 On Saturday, July 28, 2018 at 11:43:04 AM UTC-7, nafis wrote:
>
> Suppose I'm making a library and it does reference some other library
> not part of the standard library. I want to vendor those so that my 
> library
> doesn't fail if the other 3rd party developer deletes their library or
> major changes of their library(I know this sound like stupid design). And 
> I
> want to push the vendor folder on my library repo. My question: Is
> this the bad idea keep a vendor folder on the library repo.
>
> Thank you for your time.
>
 --
> 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/yASFt3PY_yg/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.
>

-- 
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] liteide x34.1 released, support go1.11 modules

[visualfc]

Hi, all.
LiteIDE X34.1 released!
This version update gocode to support go1.11 modules and vendor by source 
parser.

* LiteIDE Home

* LiteIDE Source code

* Release downloads
* 
* 

### 2018.08.12 Ver X34.1
* LiteIDE
* update gotools support go1.11 modules
* update gocode support go1.11 modules and vendor
* LiteEditor
* enable open binary file for editor
* change widget readonly by binary file (ignore text file)
* gocode
* change parser by source use gotools/types
* fix parser vendor & modules


Sent from YoMail for Gmail

-- 
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: Examples testing with two newline, but only one newline

[messju mohr]

Here is a running version that shows the original poster's problem:


On Mon, Aug 13, 2018 at 07:16:08AM -0700, gary.willoug...@victoriaplumb.com 
wrote:
>Your program doesn't work.
> 
>On Saturday, 11 August 2018 09:10:04 UTC+1, 子風 wrote:
> 
>  Hi
>  [1]https://play.golang.org/p/AIB-yJaExVu
>  When I want to use examples to test my code, I find something odd.
>  Example1 could pass, but Example2 failed
> 
>--- FAIL: Example2 (0.00s)
>got:
>hello
>.
> 
>123
>want:
>hello
>.
>123
>FAIL
>exit status 1
> 
>  It seems Examples could only show one newline.
>  Is there a solution to solve it? 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 [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. https://play.golang.org/p/AIB-yJaExVu
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. 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] Is there a way to clear a map similar to slice = slice[:0]?

[Peter Edge]

Yes, actually saw that a bit after I sent this email. Thanks for the link
though, appreciate it :-)

On Mon, Aug 13, 2018 at 11:08 AM roger peppe  wrote:

> I believe this optimisation has been implemented now.
> Have you tried using Go 1.11 beta (or Go tip) ?
> See https://tip.golang.org/doc/go1.11#performance-compiler
>
>
> On 12 August 2018 at 11:07, Peter Edge  wrote:
> > With slices, you can do
> >
> > slice = slice[:0]
> >
> > to remove the values from the slice, but keep the backing slice with the
> > same capacity (although the elements aren't marked for GC I believe, if
> > that's a concern). With maps, is there a similar pattern? I've tried:
> >
> > for key := range m {
> >  delete(m, key)
> > }
> >
> > But this doesn't seem to work, I still see allocations (and it causes a
> > significant performance hit, which makes sense).
> >
> > Even something similar to https://golang.org/cl/137880043 if we had to
> clear
> > the actual values would be great.
> >
> > --
> > 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: Examples testing with two newline, but only one newline

[gary . willoughby]

Your program doesn't work.

On Saturday, 11 August 2018 09:10:04 UTC+1, 子風 wrote:
>
> Hi
>
> https://play.golang.org/p/AIB-yJaExVu
>
> When I want to use examples to test my code, I find something odd.
> Example1 could pass, but Example2 failed
>
> --- FAIL: Example2 (0.00s)
>> got:
>> hello
>> .
>>
>> 123
>> want:
>> hello
>> .
>> 123
>> FAIL
>> exit status 1
>
>
> It seems Examples could only show one newline.
> Is there a solution to solve it? 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.

Re: [go-nuts] Is there a way to clear a map similar to slice = slice[:0]?

[roger peppe]

I believe this optimisation has been implemented now.
Have you tried using Go 1.11 beta (or Go tip) ?
See https://tip.golang.org/doc/go1.11#performance-compiler


On 12 August 2018 at 11:07, Peter Edge  wrote:
> With slices, you can do
>
> slice = slice[:0]
>
> to remove the values from the slice, but keep the backing slice with the
> same capacity (although the elements aren't marked for GC I believe, if
> that's a concern). With maps, is there a similar pattern? I've tried:
>
> for key := range m {
>  delete(m, key)
> }
>
> But this doesn't seem to work, I still see allocations (and it causes a
> significant performance hit, which makes sense).
>
> Even something similar to https://golang.org/cl/137880043 if we had to clear
> the actual values would be great.
>
> --
> 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: HTTP/2 Adventure in the Go World

[michal]

That's cool, I'm not sure if the locks on Conn object [1] are needed, could 
it just rely on locking in http2?

[1] https://github.com/posener/h2conn/blob/master/conn.go#L18

On Sunday, August 12, 2018 at 4:40:03 PM UTC+2, Eyal wrote:
>
> Hi,
> You are welcome to read a blog post I wrote about a short experience with 
> HTTP/2 and Go.
>
> https://posener.github.io/http2/
>
> Cheers,
> Eyal
>

-- 
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: CGO - http.post returns execption

[nicolas_boiteux via golang-nuts]

just opened an issue about that:
https://github.com/golang/go/issues/26952

Le dimanche 12 août 2018 23:19:23 UTC+2, nicolas...@yahoo.fr a écrit :
>
> i don't find any information about this problem :( it doesnt seems to be 
> relative to c.cstring cause when i use a simple string "hello" instead of 
> the data return the dll crash too.
>
> if i use the same code in .exe it works fine.
>
>
> Le dimanche 12 août 2018 10:33:54 UTC+2, nicolas...@yahoo.fr a écrit :
>>
>> Hello,
>>
>> I need some assistance with a little code relative to http.post client 
>> that request a remote json. 
>>
>> jsonData := map[string]string{"firstname": "Nic", "lastname": "Raboy"
>> }
>> jsonValue, _ := json.Marshal(jsonData)
>> response, err = http.Post("https://httpbin.org/post;, 
>> "application/json", bytes.NewBuffer(jsonValue))
>> defer response.Body.Close()
>> if err != nil {
>> data = fmt.Sprintf("The HTTP request failed with error %s\n", err
>> )
>> } else {
>> rawdata, _ := ioutil.ReadAll(response.Body)
>> data = string(rawdata)
>> }
>> return data
>>
>> when i try just after to retrieve the return to a string cgo variable
>>
>> result := C.CString(data)
>>
>> it returns an exception. From my understanding, it seems to be an 
>> aynchronous error message relative to http. But in this context it should 
>> be synchronous.
>>
>> Exception 0xc005 0x0 0x1e7e1af9000 0x7ffc1f804365
>> Au caractère Ligne:1 : 1
>> + .\callExtension_x64.exe .\test_script.sqf 2> log.txt
>> + 
>> + CategoryInfo  : NotSpecified: (Exception 0xc00... 
>> 0x7ffc1f804365:String) [], RemoteException
>> + FullyQualifiedErrorId : NativeCommandError
>>  
>> PC=0x7ffc1f804365
>> signal arrived during external code execution
>>
>> main._Cfunc_memmove(0x6b5b4fbdf0
>> , 0x1e7e1af7a30, 0x27ff, 0x0)
>> _cgo_gotypes.go:77 +0x55
>>
>> main.RVExtension.func2(0x6b5b4fbdf0, 0x1e7e1af7a30
>> , 0x27ff
>> , 0x1
>> )
>> C:/Users/code34/go/src/github.com/code34/armaws_x64/armaws_x64.go:
>> 50 +
>> 0xa0
>>
>> main.RVExtension(0x6b5b4fbdf0, 0x2800, 
>> 0x6b5b4febd0)
>>
>> C:/Users/code34/go/src/github.com/code34/armaws_x64/armaws_x64.go
>> :50
>>  +0x11f
>> main._cgoexpwrap_46df507b520b_RVExtension(0x6b5b4fbdf0, 0x2800, 
>> 0x6b5b4febd0)
>> _cgo_gotypes.go:122 +0x46
>>
>>
>>
>> goroutine 38 [select]:
>>
>> net/http.(*persistConn).writeLoop(
>> 0xc0420a4fc0)
>> C:/Go/src/net/http/transport.go:1822 +0x152
>>
>>
>> created by net/http.(*Transport).dialConn
>> C:/Go/src/net/http/transport.go:1238 +0x986
>>
>> goroutine 37
>>  [IO wait
>> ]:
>>
>> internal/poll.runtime_pollWait(0x1e7e1974ea0, 0x72, 0x69521b80)
>> C:/Go/src/runtime/netpoll.go:173 +0x5e
>> internal/poll.(*pollDesc).wait(0xc0421301c8, 0x72, 0x69612100, 0x0, 0x0)
>> C:/Go/src/internal/poll/fd_poll_runtime.go:85 +0xa2
>> internal/poll.(*ioSrv).ExecIO(0x69649118, 0xc042130018, 0x69504890, 0x32, 
>> 0x1, 0x1)
>> C:/Go/src/internal/poll/fd_windows.go:223 +0x13a
>> internal/poll.(*FD).Read(0xc04213, 0xc04213c400, 0x400, 0x400, 0x0, 
>> 0x0, 0x0)
>> C:/Go/src/internal/poll/fd_windows.go:484 +0x248
>> net.(*netFD).Read(0xc04213, 0xc04213c400, 0x400, 0x400, 0x692d6fe0, 
>> 0xc04204c710, 0x0)
>> C:/Go/src/net/fd_windows.go:151 +0x56
>> net.(*conn).Read(0xc042004010, 0xc04213c400, 0x400, 0x400, 0x0, 0x0, 0x0)
>> C:/Go/src/net/net.go:176 +0x71
>> crypto/tls.(*block).readFromUntil(0xc0421340c0, 0x1e7e19b, 
>> 0xc042004010, 0x5, 0xc042004010, 0x0)
>> C:/Go/src/crypto/tls/conn.go:493 +0x9d
>> crypto/tls.(*Conn).readRecord(0xc042006380, 0x69505017, 0xc0420064a0, 
>> 0x692d2270)
>> C:/Go/src/crypto/tls/conn.go:595 +0xe7
>> crypto/tls.(*Conn).Read(0xc042006380, 0xc042145000, 0x1000, 0x1000, 0x0, 
>> 0x0, 0x0)
>> C:/Go/src/crypto/tls/conn.go:1156 +0x107
>> net/http.(*persistConn).Read(0xc0420a4fc0, 0xc042145000, 0x1000, 0x1000, 
>> 0xc042113b98, 0x69284995, 0xc042012120)
>> C:/Go/src/net/http/transport.go:1453 +0x13d
>> bufio.(*Reader).fill(0xc04205c2a0)
>> C:/Go/src/bufio/bufio.go:100 +0x125
>> bufio.(*Reader).Peek(0xc04205c2a0, 0x1, 0x0, 0x0, 0x0, 0xc042012180, 0x0)
>> C:/Go/src/bufio/bufio.go:132 +0x41
>> net/http.(*persistConn).readLoop(0xc0420a4fc0)
>>
>> 
>> C:/Go/src/net/http/transport.go:1601 +
>> 0x18c
>> created by net/http.(*Transport).dialConn
>>
>> C:/Go/src/net/http/transport.go:1237 +0x961
>>
>> rax 0xc04203e000
>>
>> rbx 0xc04203ddc8
>> rcx 0x6b5b4fd3b0
>> rdi 
>> 0xc04203e000
>>
>> rsi 0xc042028180
>>
>> rbp 
>> 0xc04203dd78
>> rsp 0x6b5b4fbad8
>>
>> r8  0x1f
>> r9  0x91
>>
>> r10 0x2
>> r11 0x6b5b4fbdf0
>>
>> r12 
>> 0x
>>
>> r13 0x3
>> r14 
>> 0x2
>> r15 0x11
>> rip 0x7ffc1f804365
>> rflags  0x10202
>> cs  0x33
>>
>> fs  0x53
>>
>> gs  0x2b
>>
>>
>>

-- 
You received this message because you are 

[go-nuts] Re: Does sync.(*Pool).Put slow to cause latency spikes sometimes?

[nealhoo]

Yes, there is only pointers in sync.Pool.

I think the sync.Pool only slow during GCing is a normal behavior. If the 
sync.Pool's method slow with out GCing is a runtime issue.

I donot agree:

sync.Pool just amortizes the cost of creating garbage


The sync.Pool is reusing object and reducing creating garbage during each 
gc.

在 2018年8月13日星期一 UTC+8下午1:59:02，Tamás Gulácsi写道：
>
> sync.Pool just amortizes the cost of creating garbage, does not eliminiate 
> it...
> You have to pay for your garbage somewhere!
>
> Are you sure you put only pointers into yout Pool?
>
> 2018. augusztus 13., hétfő 6:57:48 UTC+2 időpontban nea...@gmail.com a 
> következőt írta:
>>
>> Hi,
>>
>> My services show some latency spikes > 100ms sometimes. Then I use go 
>> trace to investigate this issue. And I found that sync.(*Pool).Put maybe 
>> cause the latency spikes.
>>
>> Is there someone encounter this issue also?
>> Is it a runtime issue?
>>
>> [image: sync-pool.png]
>>
>>
>>
>>
>> go version: go version go1.10 darwin/amd64 compile to linux amd64
>>
>

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