Re: [go-nuts] Single instance of program

[Dave Cheney]

It's a Linux thing, Google abstract domain socket. 

-- 
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] golang memory allocation

[刘桂祥]

package main


import (
"fmt"
_ "net/http/pprof"
"testing"
)


// 8 Bytes/op   1 allocs/op
func BenchmarkFmt1(b *testing.B) {   
 b.ReportAllocs()
for i := 0; i < b.N; i++ {
fmt.Println(100)
}
}


// 16 Bytes/op   1 allocs/op
func BenchmarkFmt2(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
fmt.Println("hello")
}
}


// 32 Bytes/op   1 allocs/op
func BenchmarkFmt3(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
fmt.Println([]int{})
  

  }
}


// 48 Bytes/op   3 allocs/op
func BenchmarkFmt4(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
fmt.Println([]int{100})
}
}


// 64 Bytes/op   4 allocs/op
func BenchmarkFmt5(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
fmt.Println([]int{100, 200})
}
}

 go version 1.7
 
 Fmt1 : the runtime alloc 100 in heap
 Fmt2:  the runtime alloc a string header (addr len) in heap 
 Fmt3:  why the runtime alloc 32 bytes for slice header ??
 Fmt4:  why have 3 allocs and 48 bytes ??
 Fmt5:  why have 4 allocs and 64 bytes ??

-- 
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] Single instance of program

[Justin Israel]

On Thu, Oct 6, 2016 at 2:13 PM Dave Cheney  wrote:

> Stick an @ at the start of the file name, or the socket will remain on
> disk after the process has exited
>

That's even better, and doesn't need to use the Remove().
I didn't see it documented about using @ for abstract socket. Did I miss
that somewhere?


> --
> 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] Single instance of program

[Dave Cheney]

Stick an @ at the start of the file name, or the socket will remain on disk 
after the process has exited. 

-- 
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] Single instance of program

[Justin Israel]

On Thu, Oct 6, 2016 at 3:15 AM dc0d  wrote:

> Nice! Seems working!
>
> I could not get Unix Domain Socket to work, since I expected an error on
> Listen or Accept but there were no errors.
>

Works fine when I tested it using this approach:

https://play.golang.org/p/A1C5BEIP2G

func main() {
_, err := net.ListenUnix("unix", {"/tmp/unixdomain", "unix"})
if err != nil {
panic("Already locked")
}
defer os.Remove("/tmp/unixdomain")
}

​

Justin


>
> On Wednesday, October 5, 2016 at 12:00:12 AM UTC+3:30, Ingo Oeser wrote:
>
> Are you looking for something like
> https://godoc.org/github.com/nightlyone/lockfile ?
>
> --
> 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] go closure escape analysis

[刘桂祥]

  ok  very thanks!

在 2016年10月6日星期四 UTC+8上午7:49:03，Chris Manghane写道：
>
> To see the escape analysis results, compile with -gcflags "-m -m -m -m".
> The code in each of the example should be relatively similar, which is why 
> it is a bug that one of them causes the variable to escape to the heap.
>
> On Wed, Oct 5, 2016 at 4:46 PM, 刘桂祥  
> wrote:
>
>>   1: In example2_modified.go (y=x line should be *y=x ?) and that is the 
>> same as example1.go ???
>>but in example1.go y is escapted and example2.go is not.
>>  2:how do I see the compile handle closure call results ? compile para ? 
>>
>> 在 2016年10月5日星期三 UTC+8下午11:38:42，Chris Manghane写道：
>>>
>>> Sorry, poor explanation again.
>>>
>>> When a variable is used from outside a closure's scope, it is *captured* 
>>> by the closure. Usually that means that the closure function is modified to 
>>> include a reference to that variable when it is called as a regular 
>>> function. An example from the compiler: 
>>> https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/closure.go#L311
>>> .
>>>
>>> In example2, this
>>>
>>> // example2.go
>>>
>>> package main
>>>
>>> func main() {
>>>  var y int
>>>  func(x int) {
>>>  y = x
>>>  }(42)
>>> }
>>>
>>> is transformed into something like
>>>
>>> // example2_modified.go
>>>
>>> package main
>>>
>>> func main() {
>>>  var y int
>>>  func(y *int, x int) {
>>>  y = x
>>>  }(, 42)
>>> }
>>>
>>> and then the same analysis from above is applied. y should not escape to 
>>> the heap here, similar to example3.go.
>>>
>>> Hope that clarifies,
>>> Chris
>>>
>>> On Wed, Oct 5, 2016 at 6:18 AM, 刘桂祥  wrote:
>>>
   In go when closure call the out varible will pass  pointer to the 
 closure func so I doubt in example2.go y is passed  to closure 

   I don't know the compile how to analysis this and decide that can be 
 allocated in stack correctly ? 

 在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道：
>
> In example1, the // BAD: y escapes is there because y should not 
> escape from that function, but the current algorithm needs to be improved 
> for this case. In that closure, the address of y is captured as the 
> closure 
> argument p and since p is only dereferenced, the analysis should not 
> consider it to escape.
>
> In example3, the analysis above applies and y should not escape. y is 
> closed over and dereferenced, but we correctly do not mark it as escaping.
>
> In example2, y contains no pointers; it can never escape. The test was 
> to see if capturing/closing over a non-pointer value would cause it to 
> escape.
>
> It's a bit confusing, but to restate, in example1, y should not escape 
> even though it currently does.
>
> On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥  wrote:
>
>> // example1.go
>>
>> package main
>>
>>
>> func main() {
>>  var y int // BAD: y escapes
>>  func(p *int, x int) {
>>  *p = x
>>  }(, 42)
>> }
>>
>> example1.go  y escape to the heap
>>
>> // example2.go
>>
>> package main
>>
>> func main() {
>>  var y int
>>  func(x int) {
>>  y = x
>>  }(42)
>> }
>>
>>   example2.go y is not escaped and why ??
>>
>> // example3.go
>>
>> package main
>>
>> func main() {
>>  a := 100
>>  y := 
>>  func(x int) {
>>  *y = x
>>  }(42)
>> }
>>
>>  example3.go y is not escaped and why ??
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@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...@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] go closure escape analysis

['Chris Manghane' via golang-nuts]

To see the escape analysis results, compile with -gcflags "-m -m -m -m".
The code in each of the example should be relatively similar, which is why
it is a bug that one of them causes the variable to escape to the heap.

On Wed, Oct 5, 2016 at 4:46 PM, 刘桂祥  wrote:

>   1: In example2_modified.go (y=x line should be *y=x ?) and that is the
> same as example1.go ???
>but in example1.go y is escapted and example2.go is not.
>  2:how do I see the compile handle closure call results ? compile para ?
>
> 在 2016年10月5日星期三 UTC+8下午11:38:42，Chris Manghane写道：
>>
>> Sorry, poor explanation again.
>>
>> When a variable is used from outside a closure's scope, it is *captured*
>> by the closure. Usually that means that the closure function is modified to
>> include a reference to that variable when it is called as a regular
>> function. An example from the compiler: https://github.com/g
>> olang/go/blob/master/src/cmd/compile/internal/gc/closure.go#L311.
>>
>> In example2, this
>>
>> // example2.go
>>
>> package main
>>
>> func main() {
>>  var y int
>>  func(x int) {
>>  y = x
>>  }(42)
>> }
>>
>> is transformed into something like
>>
>> // example2_modified.go
>>
>> package main
>>
>> func main() {
>>  var y int
>>  func(y *int, x int) {
>>  y = x
>>  }(, 42)
>> }
>>
>> and then the same analysis from above is applied. y should not escape to
>> the heap here, similar to example3.go.
>>
>> Hope that clarifies,
>> Chris
>>
>> On Wed, Oct 5, 2016 at 6:18 AM, 刘桂祥  wrote:
>>
>>>   In go when closure call the out varible will pass  pointer to the
>>> closure func so I doubt in example2.go y is passed  to closure
>>>
>>>   I don't know the compile how to analysis this and decide that can be
>>> allocated in stack correctly ?
>>>
>>> 在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道：

 In example1, the // BAD: y escapes is there because y should not
 escape from that function, but the current algorithm needs to be improved
 for this case. In that closure, the address of y is captured as the closure
 argument p and since p is only dereferenced, the analysis should not
 consider it to escape.

 In example3, the analysis above applies and y should not escape. y is
 closed over and dereferenced, but we correctly do not mark it as escaping.

 In example2, y contains no pointers; it can never escape. The test was
 to see if capturing/closing over a non-pointer value would cause it to
 escape.

 It's a bit confusing, but to restate, in example1, y should not escape
 even though it currently does.

 On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥  wrote:

> // example1.go
>
> package main
>
>
> func main() {
>  var y int // BAD: y escapes
>  func(p *int, x int) {
>  *p = x
>  }(, 42)
> }
>
> example1.go  y escape to the heap
>
> // example2.go
>
> package main
>
> func main() {
>  var y int
>  func(x int) {
>  y = x
>  }(42)
> }
>
>   example2.go y is not escaped and why ??
>
> // example3.go
>
> package main
>
> func main() {
>  a := 100
>  y := 
>  func(x int) {
>  *y = x
>  }(42)
> }
>
>  example3.go y is not escaped and why ??
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go closure escape analysis

[刘桂祥]

  1: In example2_modified.go (y=x line should be *y=x ?) and that is the 
same as example1.go ???
   but in example1.go y is escapted and example2.go is not.
 2:how do I see the compile handle closure call results ? compile para ? 

在 2016年10月5日星期三 UTC+8下午11:38:42，Chris Manghane写道：
>
> Sorry, poor explanation again.
>
> When a variable is used from outside a closure's scope, it is *captured* 
> by the closure. Usually that means that the closure function is modified to 
> include a reference to that variable when it is called as a regular 
> function. An example from the compiler: 
> https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/closure.go#L311
> .
>
> In example2, this
>
> // example2.go
>
> package main
>
> func main() {
>  var y int
>  func(x int) {
>  y = x
>  }(42)
> }
>
> is transformed into something like
>
> // example2_modified.go
>
> package main
>
> func main() {
>  var y int
>  func(y *int, x int) {
>  y = x
>  }(, 42)
> }
>
> and then the same analysis from above is applied. y should not escape to 
> the heap here, similar to example3.go.
>
> Hope that clarifies,
> Chris
>
> On Wed, Oct 5, 2016 at 6:18 AM, 刘桂祥  
> wrote:
>
>>   In go when closure call the out varible will pass  pointer to the 
>> closure func so I doubt in example2.go y is passed  to closure 
>>
>>   I don't know the compile how to analysis this and decide that can be 
>> allocated in stack correctly ? 
>>
>> 在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道：
>>>
>>> In example1, the // BAD: y escapes is there because y should not escape 
>>> from that function, but the current algorithm needs to be improved for this 
>>> case. In that closure, the address of y is captured as the closure argument 
>>> p and since p is only dereferenced, the analysis should not consider it to 
>>> escape.
>>>
>>> In example3, the analysis above applies and y should not escape. y is 
>>> closed over and dereferenced, but we correctly do not mark it as escaping.
>>>
>>> In example2, y contains no pointers; it can never escape. The test was 
>>> to see if capturing/closing over a non-pointer value would cause it to 
>>> escape.
>>>
>>> It's a bit confusing, but to restate, in example1, y should not escape 
>>> even though it currently does.
>>>
>>> On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥  wrote:
>>>
 // example1.go

 package main


 func main() {
  var y int // BAD: y escapes
  func(p *int, x int) {
  *p = x
  }(, 42)
 }

 example1.go  y escape to the heap

 // example2.go

 package main

 func main() {
  var y int
  func(x int) {
  y = x
  }(42)
 }

   example2.go y is not escaped and why ??

 // example3.go

 package main

 func main() {
  a := 100
  y := 
  func(x int) {
  *y = x
  }(42)
 }

  example3.go y is not escaped and why ??

 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@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] [ANN] RapidMQ is released

[vadim . shakun]

RapidMQ is a pure, extremely productive, lightweight and relaible library 
for managing of the local messages queue
Full information about library you can find here: 
https://github.com/sybrexsys/RapidMQ

-- 
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: [ANN] gorram: like go run for any* function in stdlib or GOPATH

[Nate Finch]

Glad you think so :)  Suggestions and bugs welcome.  It's under active 
development, and I know some things don't work right now (like variadic 
functions), but I'd like to make it work with as wide a swath of go 
functions as I can :)  And I think that, since there's such a strong 
culture of being idiomatic in Go, not to mention implicit interfaces, that 
we can make a heck of a lot of things Just Work™.

On Wednesday, October 5, 2016 at 12:53:24 PM UTC-4, setha...@gmail.com 
wrote:
>
> That is... awesome...
>
> On Monday, October 3, 2016 at 5:00:34 PM UTC-4, Nate Finch wrote:
>>
>> get it via the canonical import path:
>>
>> go get npf.io/gorram
>>
>>
>> Code is at https://github.com/natefinch/gorram
>>
>>
>> Still a work in progress, but fun to play around with right now.
>>
>> Lets you do things like this:
>>
>>
>> $ echo 12345 | gorram encoding/base64.StdEncoding.EncodeToString
>>
>> MTIzNDU2Cg==
>>
>>
>> or
>>
>>
>> $ gorram encoding/json.Indent foo.json "" $'\t'
>>
>> {
>>
>> "foo" : "bar"
>>
>> }
>>
>>
>> or even just
>>
>>
>> $ gorram math.Sqrt 25
>>
>> 5
>>
>>
>> *does not work with every single function, if there's no obvious way to 
>> translate a CLI arg to that type.
>>
>>
>> Give it a try and give me some feedback.
>>
>

-- 
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: [ANN] gorram: like go run for any* function in stdlib or GOPATH

[sethamclean]

That is... awesome...

On Monday, October 3, 2016 at 5:00:34 PM UTC-4, Nate Finch wrote:
>
> get it via the canonical import path:
>
> go get npf.io/gorram
>
>
> Code is at https://github.com/natefinch/gorram
>
>
> Still a work in progress, but fun to play around with right now.
>
> Lets you do things like this:
>
>
> $ echo 12345 | gorram encoding/base64.StdEncoding.EncodeToString
>
> MTIzNDU2Cg==
>
>
> or
>
>
> $ gorram encoding/json.Indent foo.json "" $'\t'
>
> {
>
> "foo" : "bar"
>
> }
>
>
> or even just
>
>
> $ gorram math.Sqrt 25
>
> 5
>
>
> *does not work with every single function, if there's no obvious way to 
> translate a CLI arg to that type.
>
>
> Give it a try and give me some feedback.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go closure escape analysis

['Chris Manghane' via golang-nuts]

Sorry, poor explanation again.

When a variable is used from outside a closure's scope, it is *captured* by
the closure. Usually that means that the closure function is modified to
include a reference to that variable when it is called as a regular
function. An example from the compiler:
https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/closure.go#L311
.

In example2, this

// example2.go

package main

func main() {
 var y int
 func(x int) {
 y = x
 }(42)
}

is transformed into something like

// example2_modified.go

package main

func main() {
 var y int
 func(y *int, x int) {
 y = x
 }(, 42)
}

and then the same analysis from above is applied. y should not escape to
the heap here, similar to example3.go.

Hope that clarifies,
Chris

On Wed, Oct 5, 2016 at 6:18 AM, 刘桂祥  wrote:

>   In go when closure call the out varible will pass  pointer to the
> closure func so I doubt in example2.go y is passed  to closure
>
>   I don't know the compile how to analysis this and decide that can be
> allocated in stack correctly ?
>
> 在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道：
>>
>> In example1, the // BAD: y escapes is there because y should not escape
>> from that function, but the current algorithm needs to be improved for this
>> case. In that closure, the address of y is captured as the closure argument
>> p and since p is only dereferenced, the analysis should not consider it to
>> escape.
>>
>> In example3, the analysis above applies and y should not escape. y is
>> closed over and dereferenced, but we correctly do not mark it as escaping.
>>
>> In example2, y contains no pointers; it can never escape. The test was to
>> see if capturing/closing over a non-pointer value would cause it to escape.
>>
>> It's a bit confusing, but to restate, in example1, y should not escape
>> even though it currently does.
>>
>> On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥  wrote:
>>
>>> // example1.go
>>>
>>> package main
>>>
>>>
>>> func main() {
>>>  var y int // BAD: y escapes
>>>  func(p *int, x int) {
>>>  *p = x
>>>  }(, 42)
>>> }
>>>
>>> example1.go  y escape to the heap
>>>
>>> // example2.go
>>>
>>> package main
>>>
>>> func main() {
>>>  var y int
>>>  func(x int) {
>>>  y = x
>>>  }(42)
>>> }
>>>
>>>   example2.go y is not escaped and why ??
>>>
>>> // example3.go
>>>
>>> package main
>>>
>>> func main() {
>>>  a := 100
>>>  y := 
>>>  func(x int) {
>>>  *y = x
>>>  }(42)
>>> }
>>>
>>>  example3.go y is not escaped and why ??
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Cookies lose data when round tripped through net/http/cookiejar.Jar

[Nate Finch]

Got some insight about this from Rog Peppe.  The problem seems to step from 
the fact that the String() method on http.Cookie does different things 
based on what values are set in the cookie.  If it's just Name and Value, 
then String() returns a value suitable for a Cookie header (i.e. what you'd 
send up with a web request).  If other values (like Domain) are set, then 
String() returns the Set-Cookie header (like what you'd get from a 
website).  Since the Cookies(url) method is intended to be used for getting 
cookies to send with a web request, it strips out everything except Name 
and Value, so that String() returns the right format.

Thus, you *can't* round trip from SetCookie to GetCookies and back to 
SetCookie.  Which is really unfortunate, but not something that can be 
fixed in the go1 timeframe.

On Tuesday, October 4, 2016 at 9:23:43 PM UTC-4, Nate Finch wrote:
>
> See here: https://play.golang.org/p/E4_8NiodmK
>
> Is this intended? The cookies returned from cookiejar.Jar.Cookies() don't 
> include the domain, which is part of the key that they're stored under, so 
> they're no longer "the same" cookies.
>
>
>

-- 
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] when the runtime decide to threadcreate

[Ian Lance Taylor]

On Wed, Oct 5, 2016 at 7:09 AM, 刘桂祥  wrote:
>
>   want to ask when the runtime decide to threadcreate : long time not return
> syscall ? any others ??

The runtime creates a new thread whenever there is a goroutine ready
to run and the number of currently running goroutines is less than
GOMAXPROCS.

When a goroutine makes a system call or calls into C code, it is
considered to be no longer running (that is, it is considered to be
blocked) if it does not return quickly.

In your program each goroutine that blocks reading from stdin is
considered to be no longer running, so the runtime will start a new
thread in order to run the new goroutine created by the loop.

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.

Re: [go-nuts] Single instance of program

[dc0d]

Nice! Seems working!

I could not get Unix Domain Socket to work, since I expected an error on 
Listen or Accept but there were no errors.

On Wednesday, October 5, 2016 at 12:00:12 AM UTC+3:30, Ingo Oeser wrote:
>
> Are you looking for something like 
> https://godoc.org/github.com/nightlyone/lockfile ?

-- 
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] when the runtime decide to threadcreate

[刘桂祥]

package main


import (
"bufio"
"net/http"
_ "net/http/pprof"
"os"
"time"
)


func main() {
go func() {
http.ListenAndServe(":8080", nil)
}()
reader := bufio.NewReader(os.Stdin)
for i := 0; i < 100; i++ {
go func(id int) {
for {
data, _, _ := reader.ReadLine()
println(id, string(data))
}
}(i)
time.Sleep(1 * time.Second)
}
println("create finish!")
time.Sleep(5 * time.Second)
}

  I use curl http://localhost:8080/debug/pprof/threadcreate   see that the 
theadcreate num is always grow.
  want to ask when the runtime decide to threadcreate : long time not 
return syscall ? any others ??

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go closure escape analysis

[刘桂祥]

  In go when closure call the out varible will pass  pointer to the closure 
func so I doubt in example2.go y is passed  to closure 

  I don't know the compile how to analysis this and decide that can be 
allocated in stack correctly ? 

在 2016年10月4日星期二 UTC+8下午11:54:02，Chris Manghane写道：
>
> In example1, the // BAD: y escapes is there because y should not escape 
> from that function, but the current algorithm needs to be improved for this 
> case. In that closure, the address of y is captured as the closure argument 
> p and since p is only dereferenced, the analysis should not consider it to 
> escape.
>
> In example3, the analysis above applies and y should not escape. y is 
> closed over and dereferenced, but we correctly do not mark it as escaping.
>
> In example2, y contains no pointers; it can never escape. The test was to 
> see if capturing/closing over a non-pointer value would cause it to escape.
>
> It's a bit confusing, but to restate, in example1, y should not escape 
> even though it currently does.
>
> On Mon, Oct 3, 2016 at 11:09 PM, 刘桂祥  
> wrote:
>
>> // example1.go
>>
>> package main
>>
>>
>> func main() {
>>  var y int // BAD: y escapes
>>  func(p *int, x int) {
>>  *p = x
>>  }(, 42)
>> }
>>
>> example1.go  y escape to the heap
>>
>> // example2.go
>>
>> package main
>>
>> func main() {
>>  var y int
>>  func(x int) {
>>  y = x
>>  }(42)
>> }
>>
>>   example2.go y is not escaped and why ??
>>
>> // example3.go
>>
>> package main
>>
>> func main() {
>>  a := 100
>>  y := 
>>  func(x int) {
>>  *y = x
>>  }(42)
>> }
>>
>>  example3.go y is not escaped and why ??
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: exec.Command

[hadiesmaili85]

but i test this code it does not work!

Why??

On Wednesday, October 5, 2016 at 2:46:37 AM UTC-7, hadies...@gmail.com 
wrote:
>
> hi
>
> in the second arg in function exec.Command(), what i must put it??
>
> and any my question is :
>
> i want run a cmd command.for example : cls
>
> how can i run this method?
>

-- 
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] exec.Command

[Marvin Renich]

* hadiesmail...@gmail.com  [161005 05:46]:
> hi
> 
> in the second arg in function exec.Command(), what i must put it??
> 
> and any my question is :
> 
> i want run a cmd command.for example : cls
> 
> how can i run this method?

The second argument is a variadic argument, so you can omit it; see [1].
Here is an example of using exec.Command:

var cls = exec.Command("cls")
cls.Stdout = os.Stdout
var err = cls.Run()
if err != nil {
fmt.Fprintf(os.Stderr, "error: %s\n", err)
}

[1] https://golang.org/ref/spec#Passing_arguments_to_..._parameters

...Marvin

-- 
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] exec.Command

[hadiesmaili85]

hi

in the second arg in function exec.Command(), what i must put it??

and any my question is :

i want run a cmd command.for example : cls

how can i run this method?

-- 
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: json package error ?

[Marcin Jurczuk]

Hi,

This definitely help.
Problem solved.

W dniu poniedziałek, 3 października 2016 19:40:06 UTC+2 użytkownik 刘湃 
napisał:
>
> Try this https://play.golang.org/p/54Utd1Vsw3
>
> https://godoc.org/encoding/json#Marshal
>
> String values encode as JSON strings coerced to valid UTF-8, replacing 
> invalid bytes with the Unicode replacement rune. The angle brackets "<" and 
> ">" are escaped to "\u003c" and "\u003e" to keep some browsers from 
> misinterpreting JSON output as HTML. Ampersand "&" is also escaped to 
> "\u0026" for the same reason. This escaping can be disabled using an 
> Encoder with DisableHTMLEscaping.
>
> Marcin Jurczuk於 2016年10月3日星期一 UTC+8下午5時16分30秒寫道：
>>
>> Hi,
>>
>> I hit some issue with son.Marshal string parsing and I don't know is it 
>> package error or "this is not a bug - it's a feature".
>>
>> Here is code that doesn't work like expected:
>> https://play.golang.org/p/vAOhLCtoSh
>>
>>
>> Why I'm getting \u003c\u003 instead of << when printing printing out 
>> json ??
>>
>>

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