[go-nuts] Re: Golang crashes windows console

[Sotirios Mantziaris]

hi,

i had the same issue. My fix was to upgrade or downgrade git. The 
latest git version 2.15.0.windows.1 works ok.

On Monday, November 13, 2017 at 5:33:55 PM UTC+2, Patrick Hadlaw wrote:
>
> I've posted my problem on stack overflow and could not fix it!
>
> https://stackoverflow.com/questions/46392778/golang-crashing-windows-console
>
> I'm running Windows 10, installed go through x64 msi installer. Basically, 
> whenever I run Go in cmd with an argument (build, env, list, get...) the 
> program seems to be either closing or crashing the console after completing 
> running. So if I run go build it will work but will close console before I 
> can read any errors. The only way I can use go is by writing all go 
> commands to a file such as:
> go env > file.txt
>

-- 
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 crashes windows console

[Dave Cheney]

This has been reported previously and appears to be a bug in git which causes 
come.exe. Sorry I don’t have the details, how his could be possible escapes me, 
but I’ve long since given up being surprised by the bizarre layer violations in 
windows. 

-- 
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: How to convert from []byte to []uint32?

['Bryan Mills' via golang-nuts]

Yes, it looked like a typo to me.

Truncating the string to an even number of characters gives the same 
results as the original snippet:
https://play.golang.org/p/avf6xqnpEn

It's also not difficult to pad the input, if that's the desired behavior:
https://play.golang.org/p/Q6C9SBhQB5
(Padding without copying the whole string would be slightly more complex, 
but as Howard noted, Go style is generally to prefer simpler code.)


On Monday, November 13, 2017 at 5:31:22 PM UTC-8, peterGo wrote:
>
> Bryan,
>
> Use the test case from the question: buffer := "83f982d600c1caca7a6".
>
> https://play.golang.org/p/1gN7Y4ajOH
>
> Peter
>
> On Monday, November 13, 2017 at 7:42:16 PM UTC-5, Bryan Mills wrote:
>>
>> In this case, the "code golf" solution seems clearer: 
>> https://play.golang.org/p/Jxkf2Vheml
>>
>> On Monday, November 13, 2017 at 3:57:57 PM UTC-8, peterGo wrote:
>>>
>>> Christian,
>>>
>>> Your specialized convertCharToInt32 function, which returns []uint32, is 
>>> slow in comparison to a more general HexToUint function.
>>>
>>> BenchmarkHexToUint32-8   200088.9 ns/op   16 B/op2 allocs/op
>>> BenchmarkCharToInt32-8300   438 ns/op 96 B/op   22 allocs/op
>>>
>>> Playground: https://play.golang.org/p/OeUDEV9Xpb
>>>
>>> Peter
>>>
>>> On Monday, November 13, 2017 at 1:51:21 AM UTC-5, Christian LeMoussel 
>>> wrote:

 I have a data stream of bytes and I'd like to get array of int32 (from 
 four bytes).

 func convertCharToInt32(buffer string) []uint32 {
 const SIZEOF_INT32 = 4

 var hh = make([]byte, 2)
 var cbuffer = make([]byte, len(buffer)/2)
 var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)

 for i := 0; i < 28; i++ {
 hh[0] = buffer[i*2]
 hh[1] = buffer[i*2+1]
 if s, err := strconv.ParseUint(string(hh[:]), 16, 64); err == 
 nil {
 cbuffer[i] = byte(s)
 }
 }

 for i := range hbuffer {
 hbuffer[i] = uint32(Endian.Uint32(cbuffer[i*SIZEOF_INT32 : (i+1
 )*SIZEOF_INT32]))
 }

 return hbuffer
 }

 buffer := "83f982d600c1caca7a6"
 hbuffer := convertCharToInt32(buffer)



 The code above seems to work, but perhaps there is a built-in function 
 in Go that I've missed or there is a super cool hack that does that in one 
 instruction?




-- 
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: How to convert from []byte to []uint32?

[peterGo]

Bryan,

Use the test case from the question: buffer := "83f982d600c1caca7a6".

https://play.golang.org/p/1gN7Y4ajOH

Peter

On Monday, November 13, 2017 at 7:42:16 PM UTC-5, Bryan Mills wrote:
>
> In this case, the "code golf" solution seems clearer: 
> https://play.golang.org/p/Jxkf2Vheml
>
> On Monday, November 13, 2017 at 3:57:57 PM UTC-8, peterGo wrote:
>>
>> Christian,
>>
>> Your specialized convertCharToInt32 function, which returns []uint32, is 
>> slow in comparison to a more general HexToUint function.
>>
>> BenchmarkHexToUint32-8   200088.9 ns/op   16 B/op2 allocs/op
>> BenchmarkCharToInt32-8300   438 ns/op 96 B/op   22 allocs/op
>>
>> Playground: https://play.golang.org/p/OeUDEV9Xpb
>>
>> Peter
>>
>> On Monday, November 13, 2017 at 1:51:21 AM UTC-5, Christian LeMoussel 
>> wrote:
>>>
>>> I have a data stream of bytes and I'd like to get array of int32 (from 
>>> four bytes).
>>>
>>> func convertCharToInt32(buffer string) []uint32 {
>>> const SIZEOF_INT32 = 4
>>>
>>> var hh = make([]byte, 2)
>>> var cbuffer = make([]byte, len(buffer)/2)
>>> var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)
>>>
>>> for i := 0; i < 28; i++ {
>>> hh[0] = buffer[i*2]
>>> hh[1] = buffer[i*2+1]
>>> if s, err := strconv.ParseUint(string(hh[:]), 16, 64); err == 
>>> nil {
>>> cbuffer[i] = byte(s)
>>> }
>>> }
>>>
>>> for i := range hbuffer {
>>> hbuffer[i] = uint32(Endian.Uint32(cbuffer[i*SIZEOF_INT32 : (i+1)
>>> *SIZEOF_INT32]))
>>> }
>>>
>>> return hbuffer
>>> }
>>>
>>> buffer := "83f982d600c1caca7a6"
>>> hbuffer := convertCharToInt32(buffer)
>>>
>>>
>>>
>>> The code above seems to work, but perhaps there is a built-in function 
>>> in Go that I've missed or there is a super cool hack that does that in one 
>>> instruction?
>>>
>>>
>>>

-- 
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: How to convert from []byte to []uint32?

['Bryan Mills' via golang-nuts]

In this case, the "code golf" solution seems 
clearer: https://play.golang.org/p/Jxkf2Vheml

On Monday, November 13, 2017 at 3:57:57 PM UTC-8, peterGo wrote:
>
> Christian,
>
> Your specialized convertCharToInt32 function, which returns []uint32, is 
> slow in comparison to a more general HexToUint function.
>
> BenchmarkHexToUint32-8   200088.9 ns/op   16 B/op2 allocs/op
> BenchmarkCharToInt32-8300   438 ns/op 96 B/op   22 allocs/op
>
> Playground: https://play.golang.org/p/OeUDEV9Xpb
>
> Peter
>
> On Monday, November 13, 2017 at 1:51:21 AM UTC-5, Christian LeMoussel 
> wrote:
>>
>> I have a data stream of bytes and I'd like to get array of int32 (from 
>> four bytes).
>>
>> func convertCharToInt32(buffer string) []uint32 {
>> const SIZEOF_INT32 = 4
>>
>> var hh = make([]byte, 2)
>> var cbuffer = make([]byte, len(buffer)/2)
>> var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)
>>
>> for i := 0; i < 28; i++ {
>> hh[0] = buffer[i*2]
>> hh[1] = buffer[i*2+1]
>> if s, err := strconv.ParseUint(string(hh[:]), 16, 64); err == nil 
>> {
>> cbuffer[i] = byte(s)
>> }
>> }
>>
>> for i := range hbuffer {
>> hbuffer[i] = uint32(Endian.Uint32(cbuffer[i*SIZEOF_INT32 : (i+1)*
>> SIZEOF_INT32]))
>> }
>>
>> return hbuffer
>> }
>>
>> buffer := "83f982d600c1caca7a6"
>> hbuffer := convertCharToInt32(buffer)
>>
>>
>>
>> The code above seems to work, but perhaps there is a built-in function in 
>> Go that I've missed or there is a super cool hack that does that in one 
>> instruction?
>>
>>
>>

-- 
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] Understanding panic at addr=0x38 when calling a method on a nil interface

[keith . randall]

Filed issue https://github.com/golang/go/issues/22703

On Monday, November 13, 2017 at 3:50:58 PM UTC-8, Keith Randall wrote:
>
> Konstantin, your description is correct.  The code is trying to load a 
> function pointer out of an itab, but the pointer to the itab is nil.
> I think this is actually a bug.  If you have an interface with more than 
> pagesize/ptrsize methods in it, this code might not panic when it should.
>
>
> On Monday, November 13, 2017 at 4:46:59 AM UTC-8, Alexander Kapshuk wrote:
>>
>> On Mon, Nov 13, 2017 at 1:42 PM, Konstantin Khomoutov  
>> wrote:
>>
>>> While debugging a program which had a panic due to an attempt to call a
>>> method on a value of an interface typeš, I came across the behaviour I
>>> find strange, and would like to get help understanding what happens.
>>>
>>> The behaviour is exhibited by this simple program:
>>>
>>> ---8<
>>>  1  package main
>>>  2
>>>  3  import (
>>>  4  "fmt"
>>>  5  "os"
>>>  6  )
>>>  7
>>>  8  func main() {
>>>  9  var fi os.FileInfo
>>> 10  s := fi.Name()
>>> 11  fmt.Println(s)
>>> 12  }
>>> ---8<
>>>
>>> When built by Go 1.8.3 on Linux/amd64 and run on that same system
>>> it expectedly panics at line 10.
>>>
>>>
>>> What puzzles me, is that the address it panics is not 0x0 (which I would
>>> expect from an x86/amd64 H/W platform to stand for nil) but 0x38:
>>>
>>> ---8<
>>> $ go run foo.go
>>> panic: runtime error: invalid memory address or nil pointer dereference
>>> [signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x47d148]
>>>
>>> goroutine 1 [running]:
>>> main.main()
>>> /home/user/foo.go:10 +0x28
>>> exit status 2
>>> ---8<
>>>
>>>
>>> If I run `go tool objdump` on the generated binary, I get this
>>> (instruction codes removed for brewity):
>>>
>>> ---8<
>>> TEXT main.main(SB) /home/user/foo.go
>>> foo.go:80x47d120FS MOVQ FS:0xfff8, CX
>>> foo.go:80x47d129CMPQ 0x10(CX), SP
>>> foo.go:80x47d12dJBE 0x47d1d3
>>> foo.go:80x47d133SUBQ $0x58, SP
>>> foo.go:80x47d137MOVQ BP, 0x50(SP)
>>> foo.go:80x47d13cLEAQ 0x50(SP), BP
>>> foo.go:10   0x47d141MOVQ $0x38, AX
>>> foo.go:10   0x47d148MOVQ 0(AX), AX
>>> foo.go:10   0x47d14bMOVQ $0x0, 0(SP)
>>> foo.go:10   0x47d153CALL AX
>>> foo.go:10   0x47d155MOVQ 0x10(SP), AX
>>> foo.go:10   0x47d15aMOVQ 0x8(SP), CX
>>> foo.go:11   0x47d15fMOVQ CX, 0x30(SP)
>>> foo.go:11   0x47d164MOVQ AX, 0x38(SP)
>>> foo.go:11   0x47d169MOVQ $0x0, 0x40(SP)
>>> foo.go:11   0x47d172MOVQ $0x0, 0x48(SP)
>>> foo.go:11   0x47d17bLEAQ 0xf3de(IP), AX
>>> foo.go:11   0x47d182MOVQ AX, 0(SP)
>>> foo.go:11   0x47d186LEAQ 0x30(SP), AX
>>> foo.go:11   0x47d18bMOVQ AX, 0x8(SP)
>>> foo.go:11   0x47d190CALL runtime.convT2E(SB)
>>> foo.go:11   0x47d195MOVQ 0x10(SP), AX
>>> foo.go:11   0x47d19aMOVQ 0x18(SP), CX
>>> foo.go:11   0x47d19fMOVQ AX, 0x40(SP)
>>> foo.go:11   0x47d1a4MOVQ CX, 0x48(SP)
>>> foo.go:11   0x47d1a9LEAQ 0x40(SP), AX
>>> foo.go:11   0x47d1aeMOVQ AX, 0(SP)
>>> foo.go:11   0x47d1b2MOVQ $0x1, 0x8(SP)
>>> foo.go:11   0x47d1bbMOVQ $0x1, 0x10(SP)
>>> foo.go:11   0x47d1c4CALL fmt.Println(SB)
>>> foo.go:12   0x47d1c9MOVQ 0x50(SP), BP
>>> foo.go:12   0x47d1ceADDQ $0x58, SP
>>> foo.go:12   0x47d1d2RET
>>> foo.go:80x47d1d3CALL runtime.morestack_noctxt(SB)
>>> foo.go:80x47d1d8JMP main.main(SB)
>>> ---8<
>>>
>>> So, for the call at line 10 we have
>>>
>>> MOVQ $0x38, AX
>>> MOVQ 0(AX), AX
>>>
>>> which I translate as "load the quad word 0x38 into the register AX
>>> and then load the quad word located at offset 0 in the memory at
>>> the address located in the register AX, into that same register".
>>>
>>> That second instruction fails (since IIRC Linux maps a special
>>> sentinel page at address 0x0 to catch problems like this one).
>>>
>>>
>>> I fail to comprehend why 0x38 appears to be a constant (some magic
>>> number).  Looks like this is an offset of something.  Recalling [1],
>>> I found out Go 1.8.3 defines an Itab as
>>>
>>> type itab struct {
>>> inter  *interfacetype
>>> _type  *_type
>>> link   *itab
>>> badint32
>>> inhash int32  // has this itab been 

[go-nuts] Re: How to convert from []byte to []uint32?

[peterGo]

Christian,

Your specialized convertCharToInt32 function, which returns []uint32, is 
slow in comparison to a more general HexToUint function.

BenchmarkHexToUint32-8   200088.9 ns/op   16 B/op2 allocs/op
BenchmarkCharToInt32-8300   438 ns/op 96 B/op   22 allocs/op

Playground: https://play.golang.org/p/OeUDEV9Xpb

Peter

On Monday, November 13, 2017 at 1:51:21 AM UTC-5, Christian LeMoussel wrote:
>
> I have a data stream of bytes and I'd like to get array of int32 (from 
> four bytes).
>
> func convertCharToInt32(buffer string) []uint32 {
> const SIZEOF_INT32 = 4
>
> var hh = make([]byte, 2)
> var cbuffer = make([]byte, len(buffer)/2)
> var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)
>
> for i := 0; i < 28; i++ {
> hh[0] = buffer[i*2]
> hh[1] = buffer[i*2+1]
> if s, err := strconv.ParseUint(string(hh[:]), 16, 64); err == nil 
> {
> cbuffer[i] = byte(s)
> }
> }
>
> for i := range hbuffer {
> hbuffer[i] = uint32(Endian.Uint32(cbuffer[i*SIZEOF_INT32 : (i+1)*
> SIZEOF_INT32]))
> }
>
> return hbuffer
> }
>
> buffer := "83f982d600c1caca7a6"
> hbuffer := convertCharToInt32(buffer)
>
>
>
> The code above seems to work, but perhaps there is a built-in function in 
> Go that I've missed or there is a super cool hack that does that in one 
> instruction?
>
>
>

-- 
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: Who are the https://gophers.slack.com/ admins?

[Jon Calhoun]

I believe the people over at https://golangbridge.org/ are responsible for 
the Slack as well, so I would contact them.




On Monday, November 13, 2017 at 1:41:13 PM UTC-5, Vlad Didenko wrote:
>
> My phone got stolen, so I am locked out of the https://gophers.slack.com/ 
> 2FA.
>
> Slack tells to ask project admins to temporarily reset @FA on the account, 
> but I found no way to find who are the admins for the gophers workspace. 
> Anyone knows?
>
>
> 
>
>

-- 
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] Understanding panic at addr=0x38 when calling a method on a nil interface

[keith . randall]

Konstantin, your description is correct.  The code is trying to load a 
function pointer out of an itab, but the pointer to the itab is nil.
I think this is actually a bug.  If you have an interface with more than 
pagesize/ptrsize methods in it, this code might not panic when it should.


On Monday, November 13, 2017 at 4:46:59 AM UTC-8, Alexander Kapshuk wrote:
>
> On Mon, Nov 13, 2017 at 1:42 PM, Konstantin Khomoutov  > wrote:
>
>> While debugging a program which had a panic due to an attempt to call a
>> method on a value of an interface typeš, I came across the behaviour I
>> find strange, and would like to get help understanding what happens.
>>
>> The behaviour is exhibited by this simple program:
>>
>> ---8<
>>  1  package main
>>  2
>>  3  import (
>>  4  "fmt"
>>  5  "os"
>>  6  )
>>  7
>>  8  func main() {
>>  9  var fi os.FileInfo
>> 10  s := fi.Name()
>> 11  fmt.Println(s)
>> 12  }
>> ---8<
>>
>> When built by Go 1.8.3 on Linux/amd64 and run on that same system
>> it expectedly panics at line 10.
>>
>>
>> What puzzles me, is that the address it panics is not 0x0 (which I would
>> expect from an x86/amd64 H/W platform to stand for nil) but 0x38:
>>
>> ---8<
>> $ go run foo.go
>> panic: runtime error: invalid memory address or nil pointer dereference
>> [signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x47d148]
>>
>> goroutine 1 [running]:
>> main.main()
>> /home/user/foo.go:10 +0x28
>> exit status 2
>> ---8<
>>
>>
>> If I run `go tool objdump` on the generated binary, I get this
>> (instruction codes removed for brewity):
>>
>> ---8<
>> TEXT main.main(SB) /home/user/foo.go
>> foo.go:80x47d120FS MOVQ FS:0xfff8, CX
>> foo.go:80x47d129CMPQ 0x10(CX), SP
>> foo.go:80x47d12dJBE 0x47d1d3
>> foo.go:80x47d133SUBQ $0x58, SP
>> foo.go:80x47d137MOVQ BP, 0x50(SP)
>> foo.go:80x47d13cLEAQ 0x50(SP), BP
>> foo.go:10   0x47d141MOVQ $0x38, AX
>> foo.go:10   0x47d148MOVQ 0(AX), AX
>> foo.go:10   0x47d14bMOVQ $0x0, 0(SP)
>> foo.go:10   0x47d153CALL AX
>> foo.go:10   0x47d155MOVQ 0x10(SP), AX
>> foo.go:10   0x47d15aMOVQ 0x8(SP), CX
>> foo.go:11   0x47d15fMOVQ CX, 0x30(SP)
>> foo.go:11   0x47d164MOVQ AX, 0x38(SP)
>> foo.go:11   0x47d169MOVQ $0x0, 0x40(SP)
>> foo.go:11   0x47d172MOVQ $0x0, 0x48(SP)
>> foo.go:11   0x47d17bLEAQ 0xf3de(IP), AX
>> foo.go:11   0x47d182MOVQ AX, 0(SP)
>> foo.go:11   0x47d186LEAQ 0x30(SP), AX
>> foo.go:11   0x47d18bMOVQ AX, 0x8(SP)
>> foo.go:11   0x47d190CALL runtime.convT2E(SB)
>> foo.go:11   0x47d195MOVQ 0x10(SP), AX
>> foo.go:11   0x47d19aMOVQ 0x18(SP), CX
>> foo.go:11   0x47d19fMOVQ AX, 0x40(SP)
>> foo.go:11   0x47d1a4MOVQ CX, 0x48(SP)
>> foo.go:11   0x47d1a9LEAQ 0x40(SP), AX
>> foo.go:11   0x47d1aeMOVQ AX, 0(SP)
>> foo.go:11   0x47d1b2MOVQ $0x1, 0x8(SP)
>> foo.go:11   0x47d1bbMOVQ $0x1, 0x10(SP)
>> foo.go:11   0x47d1c4CALL fmt.Println(SB)
>> foo.go:12   0x47d1c9MOVQ 0x50(SP), BP
>> foo.go:12   0x47d1ceADDQ $0x58, SP
>> foo.go:12   0x47d1d2RET
>> foo.go:80x47d1d3CALL runtime.morestack_noctxt(SB)
>> foo.go:80x47d1d8JMP main.main(SB)
>> ---8<
>>
>> So, for the call at line 10 we have
>>
>> MOVQ $0x38, AX
>> MOVQ 0(AX), AX
>>
>> which I translate as "load the quad word 0x38 into the register AX
>> and then load the quad word located at offset 0 in the memory at
>> the address located in the register AX, into that same register".
>>
>> That second instruction fails (since IIRC Linux maps a special
>> sentinel page at address 0x0 to catch problems like this one).
>>
>>
>> I fail to comprehend why 0x38 appears to be a constant (some magic
>> number).  Looks like this is an offset of something.  Recalling [1],
>> I found out Go 1.8.3 defines an Itab as
>>
>> type itab struct {
>> inter  *interfacetype
>> _type  *_type
>> link   *itab
>> badint32
>> inhash int32  // has this itab been added to hash?
>> fun[1]uintptr // variable sized
>> }
>>
>> 0x38 is 56, and 56/sizeof(quad word) = 7, so the only further guess
>> I can make is that 0x38 is the offset of the 3rd element of the "fun"
>> field in an Itab.
>>
>> Am I 

[go-nuts] Re: Will a running GC task stop immediately once debug.SetGCPercent(-1) is called?

[keith . randall]

The runtime will still finish any in-progress garbage collection.
debug.SetGCPercent only affects the trigger point (when to start) and the 
pacing (at what rate to mark the heap).


On Monday, November 13, 2017 at 2:40:29 PM UTC-8, T L wrote:
>
> or runtime will still try to finish the current running task?
>

-- 
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: How can interfaces be comparable and at the same time functions not?

[T L]

On Monday, November 13, 2017 at 10:33:55 AM UTC-5, Stephan Schweitzer wrote:
>
> I have a question about the following code-snippet:
>
> type I interface {
>  DoSomething()
> }
> 
> type F func()
> 
> func (f F) DoSomething() {
>  f()
> }
> 
> func A() {
>  fmt.Println("A")
> }
> 
> func B() {
>  fmt.Println("B")
> }
> 
> func test() {
>  var _a F = A
>  var _b F = B
>  var a I = _a
>  var b I = _b
> 
>  if a == b { // 2. No compile error but panic
>   // Code
>  }
> }
>
> It seems to me, that I can break the type system with simple assignments. 
>

Yes, interface is run time generic. It has both good points and bad points.
It is a trade-off. And there are many trade-offs in Go design.
 

> I do not propose that functions should be comparable. My questions are:
>
>- Why are interfaces comparable by default? 
>- Why is it not possible to mark an interface as comparable resp. not 
>comparable?
>- Why is it not possible do define user defined-equality?
>- What is the motivation in this language design?
>
> Thanks
> Stephan 
>

-- 
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] Will a running GC task stop immediately once debug.SetGCPercent(-1) is called?

[T L]

or runtime will still try to finish the current running task?

-- 
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 doesn't sync.Cond embed sync.Locker?

[T L]

On Monday, November 13, 2017 at 10:10:22 AM UTC-5, Thomas Bushnell, BSG 
wrote:
>
> Sometimes you want multiple Conds which share the same Locker. When you 
> want it, it's frequently essential and very annoying if you can't have it.
>

Embedding doesn't prevent this.

I ask this question is for I think embedding will may code a little pretty. 
:)
 

>
> On Sun, Nov 12, 2017 at 7:02 PM T L > 
> wrote:
>
>> .
>>
>> -- 
>> 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] Re: network programming about go

[Justin Israel]

On Mon, Nov 13, 2017 at 4:00 PM <2891132l...@gmail.com> wrote:

> I know your meaning.But I still can't get the result I want.
> this is the server program:
> package main
>
> import (
> "fmt"
> "net"
> "os"
> "strings"
> )
>
> func main() {
>
> listener, err := net.Listen("tcp", "0.0.0.0:400")
> checkError(err)
> for i := 0; i < 10; i++ {
> conn, err := listener.Accept()
> if err != nil {
> continue
> }
> handleClient(conn)
> conn.Close()
> }
> }
> func handleClient(conn net.Conn) {
> var buf [512]byte
> for {
> n, err := conn.Read(buf[0:])
> if err != nil {
> return
> }
> rAddr := conn.RemoteAddr()
> fmt.Println("receive from client:", rAddr.String(), string(buf[0:n]))
> aa := string("nice to meet you")
> _, err2 := conn.Write([]byte("welcome client!"))
> if strings.Contains(string(buf[0:n]), aa) {
> _, err2 = conn.Write([]byte("nice to meet you too"))
> }
> checkError(err2)
> n, err = conn.Read(buf[0:])
> if err != nil {
> return
> }
> }
> }
> func checkError(err error) {
> if err != nil {
> fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
> os.Exit(1)
> }
> }
>
>
> this is the client program:
> package main
>
> import (
> "fmt"
> "net"
> "os"
> )
>
> func main() {
> var buf [512]byte
> if len(os.Args) != 2 {
> fmt.Fprintf(os.Stderr, "usage:%s host:port\n", os.Args[0])
> }
> _, err := net.ResolveTCPAddr("tcp", "127.0.0.1:400")
> checkError(err)
> conn, err := net.Dial("tcp", "127.0.0.1:400")
> checkError(err)
> rAddr := conn.RemoteAddr()
> for {
> n, err := conn.Write([]byte("hello server!"))
> n, err = conn.Write([]byte(" nice to meet you"))
> checkError(err)
> n, err = conn.Read(buf[0:])
> if err != nil {
> return
> }
> fmt.Println("reply from server:", rAddr.String(), string(buf[0:n]))
> n, err = conn.Read(buf[0:])
> if err != nil {
> return
> }
> conn.Close()
> os.Exit(0)
> }
> }
> func checkError(err error) {
> if err != nil {
> fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
> os.Exit(1)
> }
> }
>
>
> The program still don't print "nice to meet you too". Can you help me
> modifying and writing down for me??
>

You have altered the client code to again write() two times in a row
without ready the response, thus it is possible for both the server and the
client to block. There should also not be a conditional write() in the
server. It should always be consistently request-reply. I've reformatted
your server and client code, trying to keep as much of your existing logic
as possible:

Server:
https://play.golang.org/p/CeChTes_yv

Client:
https://play.golang.org/p/CVfIpBhsiz

There are better ways to write this, but just keeping it simple and close
to your original code you can see that the server is set up to first do a
handshake, and then goes into a loop where it reads requests and always
replies with something. Then the client does a couple request-reply
operations. There is always a matching read-write exchange going on.

Hopefully this helps to clarify where you had made the error in your
original program?


>
>
>
> 在 2017年11月13日星期一 UTC+8上午2:32:47，Justin Israel写道：
>
>>
>>
>> On Sun, Nov 12, 2017, 10:11 PM <28911...@gmail.com> wrote:
>>
>>> So how to modify my program correctly??I try to add read in different
>>> place but it still can't get the result I want.
>>>
>>
>> Make sure your server is doing:
>>  read, write, read, write
>>
>> And your client is doing:
>>  write, read, write, read
>>
>> But honestly it becomes hard to keep track and line up the two when you
>> are complicating the server handler loop. Why not just simplify the server
>> so that it always just reads, checks the value and writes something back,
>> then loops again? And the client would make sure to always write and then
>> read.
>> You have a conditional write on the server so that means if a client
>> doesn't say the correct phrase, it won't know if reading afterwards is
>> going to block forever.
>>
>>
>>> 在 2017年11月12日星期日 UTC+8上午5:05:49，Justin Israel写道：



 On Sun, Nov 12, 2017, 10:03 AM Justin Israel 
 wrote:

>>>
>
> On Sat, Nov 11, 2017, 9:55 PM <28911...@gmail.com> wrote:
>
>>  this is the server program：
>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "net"
>>> "os"
>>>
>> "strings"
>>> )
>>>
>>> func main() {
>>>
>>> listener, err := net.Listen("tcp", "0.0.0.0:400")
>>>
>> checkError(err)
>>> for i := 0; i < 10; i++ {
>>> conn, err := listener.Accept()
>>> if err != nil {
>>> continue
>>> }
>>> handleClient(conn)
>>> conn.Close()
>>> }
>>> }
>>> func handleClient(conn net.Conn) {
>>> var buf [512]byte
>>> for {
>>> n, err := conn.Read(buf[0:])
>>> if err != nil {
>>> return
>>> }
>>> rAddr := conn.RemoteAddr()
>>> fmt.Println("receive from client", rAddr.String(), string(buf[0:n]))
>>>
>> n, err2 := conn.Write([]byte("welcome client!"))
>>>
>> if err2 != nil {
>>> return
>>> }
>>>
>> aa := strin

Re: [go-nuts] net/http: Server closeIdleConns does not close StateNew connections

[André Carvalho]

I also ran into this issue recently. I think this is a dup of
https://github.com/golang/go/issues/21204. This issue can be mitigated if
you set some reasonable ReadTimeout on the http.Server, which causes the
http.StateNew connection to timeout (a connection stays in this state until
something is read from it).

I was thinking about working on this for 1.11 but I'm not sure what would
be the solution. Is it actually safe to just close the http.StateNew
connections?

Att,
André Carvalho
===
+55 21 98739-1097 / br.linkedin.com/in/andrestc/


2017-11-13 11:42 GMT-02:00 Kevin Burge :

> I recently ran into an issue where Chrome was opening additional
> connections to my http Server. When I went close to the Go app, instead of
> just immediately closing after calling server.Shutdown, in lingered until
> the server was forcefully shutdown by my shutdown context.  The issue is
> that closeIdleConns called by Shutdown does not close connections in the
> StateNew state.  I read somewhere else that this connection state is
> extremely rare, but, my Chrome does this with my app.  Even closing the tab
> does not close these extra connections. The only way to terminate the
> connection is to use Chrome's internal connection management or close the
> browse.
>
> But, the point is, why wouldn't the server just shutdown (via Shutdown) if
> all the connections are either StateIdle or StateNew (idle but never used)?
> I realize the Server code is expecting StateNew connections to become
> StateActive, but... in Chrome's case, it didn't.
>
> https://github.com/golang/go/issues/22682
>
> https://play.golang.org/p/dP4vQZkKdx
>
> Kevin
>
> --
> 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] Support for vsan mgmt APIs in govmomi

[nkhan]

Is there support for vsan mgmt APIs in govmomi similar to pyvmomi? What I 
am specifically looking for is to be able to query vsan cluster health 
summary

-- 
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: [code review] Exercise documenting a Go project

[Vlad Didenko]

Concrete questions after the question feedback at Stack Exchange:

Specific features used as user-facing conveniences are:

 - Provided the license in a standard location
 - Most useful API functions highlighted in the front-page README
 - All Exported functions documented via GoDoc, made sure it correctly 
published to Go's GoDoc  website
 - Integrated *Travis CI* continuous build
 - Followed semantic versioning guidelines

Controversially:

 - Marked the `dev` branch as default instead of `master`
 - Used the `0.1.0` tag instead of beta designation, like `1.0.0-beta.1`
 - Tagged minor patch as `0.1.1` after the original `0.1.0` release
 - Even though non-master default branch triggers a bug in the Go Report 
Card , still included 
the badge, albeit it reviews a previous version of the code.

Should any of that be done differently, or is something missing?

On Monday, November 13, 2017 at 12:41:13 PM UTC-6, Vlad Didenko wrote:

> *fst* is the package I posted to practice community-related workflows, 
> including writing documentation, using *travis-ci*, setting up vanity URL 
> redirection. The *fst* package adds convenience routines for testing 
> filesystem-related logic, helps to create, clone, cleanup, and compare 
> directory trees.
>
>
> It would be great to have some feedback about how approachable the package 
> is - both from the user-facing information and from API perspective.
>
>
> The package repository is at: github.com/didenko/fst 
> 
>
> If more convenient, I have also opened  the question on StackExchange 
> 
>
> 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] Who are the https://gophers.slack.com/ admins?

[Vlad Didenko]

My phone got stolen, so I am locked out of the https://gophers.slack.com/ 
2FA.

Slack tells to ask project admins to temporarily reset @FA on the account, 
but I found no way to find who are the admins for the gophers workspace. 
Anyone knows?



-- 
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] [code review] Exercise documenting a Go project

[Vlad Didenko]

*fst* is the package I posted to practice community-related workflows, 
including writing documentation, using *travis-ci*, setting up vanity URL 
redirection. The *fst* package adds convenience routines for testing 
filesystem-related logic, helps to create, clone, cleanup, and compare 
directory trees.


It would be great to have some feedback about how approachable the package 
is - both from the user-facing information and from API perspective.


The package repository is at: github.com/didenko/fst 


If more convenient, I have also opened  the question on StackExchange 


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: Simple exec.Command() program

[bucarr]

>
> You guys are great.  Not only did you explain at length, what I was 
> misunderstanding,  but you offered several solutions.
>

Thanks to one and all!
 

-- 
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: How to convert from []byte to []uint32?

[howardcshaw]

The hack would be to use unsafe after converting it to a byte slice to cast 
to a Pointer and cast that back to a uint32 slice. This is bad. Do not do 
this.

Go's ethos is pretty strongly against 'super cool hacks' or 'code golf' 
style statements that perform magic to stuff a lot of code into one 
instruction. Indeed, Go is pretty much the opposite - plain code that does 
what it appears to do with minimal magic, for maximum long-term and 
large-group maintainability of the codebase.

This StackOverflow answer provides an example of the unsafe 
way: 
https://stackoverflow.com/questions/11924196/convert-between-slices-of-different-types

As it also says, this is strongly not recommended.

-- 
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] How can interfaces be comparable and at the same time functions not?

['Axel Wagner' via golang-nuts]

Oh, and FWIW:

On Mon, Nov 13, 2017 at 12:45 PM, 'Stephan Schweitzer' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> It seems to me, that I can break the type system with simple assignments.
>

For that definition of "breaking the type system", you don't even need
assignments:

func main() {
var v error
v.Error()
}

Creating panics is basically trivial to do :)

-- 
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] How can interfaces be comparable and at the same time functions not?

['Axel Wagner' via golang-nuts]

On Mon, Nov 13, 2017 at 12:45 PM, 'Stephan Schweitzer' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
>- Why are interfaces comparable by default?
>
> A very common comparison on interfaces is "if err == io.EOF". It also
enables you, in general, to use interfaces as map keys (or, for example,
what context.Context does, which is slightly different, but also relies on
interface-comparisons).
So, the answer is "because it enables some useful patterns".

>
>- Why is it not possible to mark an interface as comparable resp. not
>comparable?
>
> In general, Go doesn't have a widely used notion of "marking a type". I
assume this particular problem was considered rarely relevant to the degree
that it didn't deserve its own language feature.

>
>- Why is it not possible do define user defined-equality?
>
> There is an FAQ item  about this.


>
>- What is the motivation in this language design?
>
> I'm not sure what you are asking here. If it is about the specific choices
you pointed out, they are answered above to some degree. If it is about
"what principles guided Go's design" in general, this article
 gives a good overview.

-- 
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: Server closeIdleConns does not close StateNew connections

[Kevin Burge]

I recently ran into an issue where Chrome was opening additional 
connections to my http Server. When I went close to the Go app, instead of 
just immediately closing after calling server.Shutdown, in lingered until 
the server was forcefully shutdown by my shutdown context.  The issue is 
that closeIdleConns called by Shutdown does not close connections in the 
StateNew state.  I read somewhere else that this connection state is 
extremely rare, but, my Chrome does this with my app.  Even closing the tab 
does not close these extra connections. The only way to terminate the 
connection is to use Chrome's internal connection management or close the 
browse.

But, the point is, why wouldn't the server just shutdown (via Shutdown) if 
all the connections are either StateIdle or StateNew (idle but never used)? 
I realize the Server code is expecting StateNew connections to become 
StateActive, but... in Chrome's case, it didn't.

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

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

Kevin

-- 
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 crashes windows console

[Patrick Hadlaw]

I've posted my problem on stack overflow and could not fix it!
https://stackoverflow.com/questions/46392778/golang-crashing-windows-console

I'm running Windows 10, installed go through x64 msi installer. Basically, 
whenever I run Go in cmd with an argument (build, env, list, get...) the 
program seems to be either closing or crashing the console after completing 
running. So if I run go build it will work but will close console before I 
can read any errors. The only way I can use go is by writing all go 
commands to a file such as:
go env > file.txt

-- 
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] How can interfaces be comparable and at the same time functions not?

['Stephan Schweitzer' via golang-nuts]

I have a question about the following code-snippet:

type I interface {
 DoSomething()
}

type F func()

func (f F) DoSomething() {
 f()
}

func A() {
 fmt.Println("A")
}

func B() {
 fmt.Println("B")
}

func test() {
 var _a F = A
 var _b F = B
 var a I = _a
 var b I = _b

 if a == b { // 2. No compile error but panic
  // Code
 }
}

It seems to me, that I can break the type system with simple assignments. 

I do not propose that functions should be comparable. My questions are:

   - Why are interfaces comparable by default? 
   - Why is it not possible to mark an interface as comparable resp. not 
   comparable?
   - Why is it not possible do define user defined-equality?
   - What is the motivation in this language design?

Thanks
Stephan 

-- 
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 doesn't sync.Cond embed sync.Locker?

['Thomas Bushnell, BSG' via golang-nuts]

Sometimes you want multiple Conds which share the same Locker. When you
want it, it's frequently essential and very annoying if you can't have it.

On Sun, Nov 12, 2017 at 7:02 PM T L  wrote:

> .
>
> --
> 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: How to convert from []byte to []uint32?

[Dmitry Savintsev]

Hi Christian, 
just a form note - it would be preferable and easier for the readers to put 
a code snippet into https://play.golang.org and share the link, similar to 
this one:
https://play.golang.org/p/p3TNDze923

It also helps to make sure that program is syntactically correct (not clear 
in your example what "Endian" refers to - binary.LittleEndian?) and the 
example can be run in the Playground.

Take a look at examples and API docs in 
https://golang.org/pkg/encoding/binary/ - they should cover what the stdlib 
provides for conversions.

On Monday, November 13, 2017 at 7:51:21 AM UTC+1, Christian LeMoussel wrote:
>
> I have a data stream of bytes and I'd like to get array of int32 (from 
> four bytes).
>
> func convertCharToInt32(buffer string) []uint32 {
> const SIZEOF_INT32 = 4
>
> var hh = make([]byte, 2)
> var cbuffer = make([]byte, len(buffer)/2)
> var hbuffer = make([]uint32, len(cbuffer)/SIZEOF_INT32)
>
> for i := 0; i < 28; i++ {
> hh[0] = buffer[i*2]
> hh[1] = buffer[i*2+1]
> if s, err := strconv.ParseUint(string(hh[:]), 16, 64); err == nil 
> {
> cbuffer[i] = byte(s)
> }
> }
>
> for i := range hbuffer {
> hbuffer[i] = uint32(Endian.Uint32(cbuffer[i*SIZEOF_INT32 : (i+1)*
> SIZEOF_INT32]))
> }
>
> return hbuffer
> }
>
> buffer := "83f982d600c1caca7a6"
> hbuffer := convertCharToInt32(buffer)
>
>
>
> The code above seems to work, but perhaps there is a built-in function in 
> Go that I've missed or there is a super cool hack that does that in one 
> instruction?
>
>
>

-- 
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] fetching URLs Concurrently

[Ayan George]

On 11/13/2017 04:10 AM, 2891132l...@gmail.com wrote:

> for range os.Args[1:] {
>   fmt.Println(<-ch)
>      }
>      fmt.Printf("%.2fs elasped\n", time.Since(start).Seconds())
> }

If I understand correctly, you want fetch() to get each URL twice but
you only read from the 'ch' channel once per URL.

So if I passed it 3 urls, we should expect to receive at least 6
responses back on ch but you only read from it 3 times.

If that loop above was something more like (and this is a kludge):

for range append(os.Args[1:], os.Args[1:]...) {
  fmt.Println(<-ch)
}

or maybe better:

for i := 0; i < len(os.Args[1:]) * 2; i++ {
  fmt.Println(<-ch)
}

The problem is that you return from fetch() early if there is an error
so you might end up blocking on <-ch forever because the number of sends
to that channel will not match the number of receives.

If I were you, I'd consider using a sync.WaitGroup to wait for all of
the fetch() calls to complete and store the results in a buffered channel.

Once all of the fetch() calls are done, you can close the channel and
range over it like this:

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


-- 
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] Understanding panic at addr=0x38 when calling a method on a nil interface

[Alexander Kapshuk]

On Mon, Nov 13, 2017 at 1:42 PM, Konstantin Khomoutov 
wrote:

> While debugging a program which had a panic due to an attempt to call a
> method on a value of an interface typeš, I came across the behaviour I
> find strange, and would like to get help understanding what happens.
>
> The behaviour is exhibited by this simple program:
>
> ---8<
>  1  package main
>  2
>  3  import (
>  4  "fmt"
>  5  "os"
>  6  )
>  7
>  8  func main() {
>  9  var fi os.FileInfo
> 10  s := fi.Name()
> 11  fmt.Println(s)
> 12  }
> ---8<
>
> When built by Go 1.8.3 on Linux/amd64 and run on that same system
> it expectedly panics at line 10.
>
>
> What puzzles me, is that the address it panics is not 0x0 (which I would
> expect from an x86/amd64 H/W platform to stand for nil) but 0x38:
>
> ---8<
> $ go run foo.go
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x47d148]
>
> goroutine 1 [running]:
> main.main()
> /home/user/foo.go:10 +0x28
> exit status 2
> ---8<
>
>
> If I run `go tool objdump` on the generated binary, I get this
> (instruction codes removed for brewity):
>
> ---8<
> TEXT main.main(SB) /home/user/foo.go
> foo.go:80x47d120FS MOVQ FS:0xfff8, CX
> foo.go:80x47d129CMPQ 0x10(CX), SP
> foo.go:80x47d12dJBE 0x47d1d3
> foo.go:80x47d133SUBQ $0x58, SP
> foo.go:80x47d137MOVQ BP, 0x50(SP)
> foo.go:80x47d13cLEAQ 0x50(SP), BP
> foo.go:10   0x47d141MOVQ $0x38, AX
> foo.go:10   0x47d148MOVQ 0(AX), AX
> foo.go:10   0x47d14bMOVQ $0x0, 0(SP)
> foo.go:10   0x47d153CALL AX
> foo.go:10   0x47d155MOVQ 0x10(SP), AX
> foo.go:10   0x47d15aMOVQ 0x8(SP), CX
> foo.go:11   0x47d15fMOVQ CX, 0x30(SP)
> foo.go:11   0x47d164MOVQ AX, 0x38(SP)
> foo.go:11   0x47d169MOVQ $0x0, 0x40(SP)
> foo.go:11   0x47d172MOVQ $0x0, 0x48(SP)
> foo.go:11   0x47d17bLEAQ 0xf3de(IP), AX
> foo.go:11   0x47d182MOVQ AX, 0(SP)
> foo.go:11   0x47d186LEAQ 0x30(SP), AX
> foo.go:11   0x47d18bMOVQ AX, 0x8(SP)
> foo.go:11   0x47d190CALL runtime.convT2E(SB)
> foo.go:11   0x47d195MOVQ 0x10(SP), AX
> foo.go:11   0x47d19aMOVQ 0x18(SP), CX
> foo.go:11   0x47d19fMOVQ AX, 0x40(SP)
> foo.go:11   0x47d1a4MOVQ CX, 0x48(SP)
> foo.go:11   0x47d1a9LEAQ 0x40(SP), AX
> foo.go:11   0x47d1aeMOVQ AX, 0(SP)
> foo.go:11   0x47d1b2MOVQ $0x1, 0x8(SP)
> foo.go:11   0x47d1bbMOVQ $0x1, 0x10(SP)
> foo.go:11   0x47d1c4CALL fmt.Println(SB)
> foo.go:12   0x47d1c9MOVQ 0x50(SP), BP
> foo.go:12   0x47d1ceADDQ $0x58, SP
> foo.go:12   0x47d1d2RET
> foo.go:80x47d1d3CALL runtime.morestack_noctxt(SB)
> foo.go:80x47d1d8JMP main.main(SB)
> ---8<
>
> So, for the call at line 10 we have
>
> MOVQ $0x38, AX
> MOVQ 0(AX), AX
>
> which I translate as "load the quad word 0x38 into the register AX
> and then load the quad word located at offset 0 in the memory at
> the address located in the register AX, into that same register".
>
> That second instruction fails (since IIRC Linux maps a special
> sentinel page at address 0x0 to catch problems like this one).
>
>
> I fail to comprehend why 0x38 appears to be a constant (some magic
> number).  Looks like this is an offset of something.  Recalling [1],
> I found out Go 1.8.3 defines an Itab as
>
> type itab struct {
> inter  *interfacetype
> _type  *_type
> link   *itab
> badint32
> inhash int32  // has this itab been added to hash?
> fun[1]uintptr // variable sized
> }
>
> 0x38 is 56, and 56/sizeof(quad word) = 7, so the only further guess
> I can make is that 0x38 is the offset of the 3rd element of the "fun"
> field in an Itab.
>
> Am I correct?
> If not, what does that 0x38 stand for?
>
> 1. https://research.swtch.com/interfaces
>
> --
> 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.
>

Incidentally, this code in question does panic at addr=0x0 when run from
within the Go Play

[go-nuts] Understanding panic at addr=0x38 when calling a method on a nil interface

[Konstantin Khomoutov]

While debugging a program which had a panic due to an attempt to call a
method on a value of an interface typeš, I came across the behaviour I
find strange, and would like to get help understanding what happens.

The behaviour is exhibited by this simple program:

---8<
 1  package main
 2  
 3  import (
 4  "fmt"
 5  "os"
 6  )
 7  
 8  func main() {
 9  var fi os.FileInfo
10  s := fi.Name()
11  fmt.Println(s)
12  }
---8<

When built by Go 1.8.3 on Linux/amd64 and run on that same system
it expectedly panics at line 10.


What puzzles me, is that the address it panics is not 0x0 (which I would
expect from an x86/amd64 H/W platform to stand for nil) but 0x38:

---8<
$ go run foo.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x47d148]

goroutine 1 [running]:
main.main()
/home/user/foo.go:10 +0x28
exit status 2
---8<


If I run `go tool objdump` on the generated binary, I get this
(instruction codes removed for brewity):

---8<
TEXT main.main(SB) /home/user/foo.go
foo.go:80x47d120FS MOVQ FS:0xfff8, CX   
foo.go:80x47d129CMPQ 0x10(CX), SP   
foo.go:80x47d12dJBE 0x47d1d3
foo.go:80x47d133SUBQ $0x58, SP  
foo.go:80x47d137MOVQ BP, 0x50(SP)   
foo.go:80x47d13cLEAQ 0x50(SP), BP   
foo.go:10   0x47d141MOVQ $0x38, AX  
foo.go:10   0x47d148MOVQ 0(AX), AX  
foo.go:10   0x47d14bMOVQ $0x0, 0(SP)
foo.go:10   0x47d153CALL AX 
foo.go:10   0x47d155MOVQ 0x10(SP), AX   
foo.go:10   0x47d15aMOVQ 0x8(SP), CX
foo.go:11   0x47d15fMOVQ CX, 0x30(SP)   
foo.go:11   0x47d164MOVQ AX, 0x38(SP)   
foo.go:11   0x47d169MOVQ $0x0, 0x40(SP) 
foo.go:11   0x47d172MOVQ $0x0, 0x48(SP) 
foo.go:11   0x47d17bLEAQ 0xf3de(IP), AX 
foo.go:11   0x47d182MOVQ AX, 0(SP)  
foo.go:11   0x47d186LEAQ 0x30(SP), AX   
foo.go:11   0x47d18bMOVQ AX, 0x8(SP)
foo.go:11   0x47d190CALL runtime.convT2E(SB)
foo.go:11   0x47d195MOVQ 0x10(SP), AX   
foo.go:11   0x47d19aMOVQ 0x18(SP), CX   
foo.go:11   0x47d19fMOVQ AX, 0x40(SP)   
foo.go:11   0x47d1a4MOVQ CX, 0x48(SP)   
foo.go:11   0x47d1a9LEAQ 0x40(SP), AX   
foo.go:11   0x47d1aeMOVQ AX, 0(SP)  
foo.go:11   0x47d1b2MOVQ $0x1, 0x8(SP)  
foo.go:11   0x47d1bbMOVQ $0x1, 0x10(SP) 
foo.go:11   0x47d1c4CALL fmt.Println(SB)
foo.go:12   0x47d1c9MOVQ 0x50(SP), BP   
foo.go:12   0x47d1ceADDQ $0x58, SP  
foo.go:12   0x47d1d2RET 
foo.go:80x47d1d3CALL runtime.morestack_noctxt(SB)   
foo.go:80x47d1d8JMP main.main(SB)   
---8<

So, for the call at line 10 we have

MOVQ $0x38, AX
MOVQ 0(AX), AX

which I translate as "load the quad word 0x38 into the register AX
and then load the quad word located at offset 0 in the memory at
the address located in the register AX, into that same register".

That second instruction fails (since IIRC Linux maps a special
sentinel page at address 0x0 to catch problems like this one).


I fail to comprehend why 0x38 appears to be a constant (some magic
number).  Looks like this is an offset of something.  Recalling [1],
I found out Go 1.8.3 defines an Itab as

type itab struct {  

inter  *interfacetype   

_type  *_type   

link   *itab   

Re: [go-nuts] Re: OpenCL or CUDA bindings

[Christian LeMoussel]

For CUDA you have, cu package that provides an idiomatic interface to the 
CUDA Driver API. https://github.com/chewxy/cu

-- 
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] driver.Rows -> sql.Rows

[Tamás Gulácsi]

This has already been asked at golang-sql 
(https://groups.google.com/forum/#!topic/golang-sql/HNvcgScdyt8), but no 
answer yet.
Maybe the wider audience here has a solution.

Hi,

Is there a way to convert a driver.Rows to an sql.Rows ?
Oracle is a strange, inconsistent beast where you can return a cursor from 
a statement executed with Exec.
gopkg.in/goracle.v2 returns this as driver.Rows, but that's uneasy to use.

Maybe a helper for use a driver.Rows as an sql.Rows could be enough.

Or any other idea?
What to return from the driver?

Thanks,
Tamás Gulácsi

-- 
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: fetching URLs Concurrently

[Nilsocket]

package main

import (
"fmt"
"io"
"io/ioutil"
"net/http"
"os"
"sync"
"time"
)

var wg sync.WaitGroup

func main() {
start := time.Now()
ch := make(chan string)
for _, url := range os.Args[1:] {
wg.Add(1)
go fetch(url, ch)
}

for range os.Args[1:] {
for i := 0; i < 2; i++ {
fmt.Println(<-ch)
}
}
wg.Wait()
fmt.Printf("%.2fs elasped\n", time.Since(start).Seconds())
}
func fetch(url string, ch chan<- string) {
for i := 0; i < 2; i++ {
start := time.Now()
resp, err := http.Get(url)
if err != nil {
ch <- fmt.Sprint(err)
return
}
nbytes, err := io.Copy(ioutil.Discard, resp.Body)
resp.Body.Close()
if err != nil {
ch <- fmt.Sprintf("while reading %s %v", url, err)
return
}
secs := time.Since(start).Seconds()
ch <- fmt.Sprintf("%.2fs %7d %s", secs, nbytes, url)
}
wg.Done()
}

//You need to use waitgroups, your go-routines will execute,
//but your main program exits before its go-routines.

-- 
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: fetching URLs Concurrently

[Nilsocket]

Could you edit your question, it's unclear and format your code.

-- 
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] fetching URLs Concurrently

[2891132love]

I try writing the program and run it. the program is as following:
package main

import (
   "fmt"
"io"
"io/ioutil"
"net/http"
"os"
"time"
)

func main() {
start := time.Now()
ch := make(chan string)
for _, url := range os.Args[1:] {
 go fetch(url, ch)
  }
for range os.Args[1:] {
  fmt.Println(<-ch)
 }
 fmt.Printf("%.2fs elasped\n", time.Since(start).Seconds())
}
func fetch(url string, ch chan<- string) {
 start := time.Now()
 resp, err := http.Get(url)
 if err != nil {
  ch <- fmt.Sprint(err)
  return
 }
 nbytes, err := io.Copy(ioutil.Discard, resp.Body)
 resp.Body.Close()
 if err != nil {
  ch <- fmt.Sprintf("while reading %s %v", url, err)
  return
 }
 secs := time.Since(start).Seconds()
 ch <- fmt.Sprintf("%.2fs  %7d  %s", secs, nbytes, url)
  i++
}
the question is how to run fetch twice in succession to see the reported 
time changes.I changed the fetch function :
package main

import (
   "fmt"
"io"
"io/ioutil"
"net/http"
"os"
"time"
)

func main() {
start := time.Now()
ch := make(chan string)
for _, url := range os.Args[1:] {
 go fetch(url, ch)
  }
for range os.Args[1:] {
  fmt.Println(<-ch)
 }
 fmt.Printf("%.2fs elasped\n", time.Since(start).Seconds())
}
func fetch(url string, ch chan<- string) {
 for i:=0;i<2;i++{
 start := time.Now()
 resp, err := http.Get(url)
 if err != nil {
   ch <- fmt.Sprint(err)
   return
}
   nbytes, err := io.Copy(ioutil.Discard, resp.Body)
   resp.Body.Close()
   if err != nil {
  ch <- fmt.Sprintf("while reading %s %v", url, err)
 return
}
secs := time.Since(start).Seconds()
ch <- fmt.Sprintf("%.2fs  %7d  %s", secs, nbytes, url)
 }
}
But the result can't change and it only runs for one time not two time.Why 
and how to solve it?? 





































}  i++  ch <- fmt.Sprintf("%.2fs  %7d  %s", secs, nbytes, url)  secs := 
time.Since(start).Seconds()  }   return   ch <- fmt.Sprintf("while reading 
%s %v", url, err)  if err != nil {  resp.Body.Close()  nbytes, err := 
io.Copy(ioutil.Discard, resp.Body)  }   return   ch <- fmt.Sprint(err)  if 
err != nil {  resp, err := http.Get(url)  start := time.Now()func fetch(url 
string, ch chan<- string) {} fmt.Printf("%.2fs elasped\n", 
time.Since(start).Seconds()) }  fmt.Println(<-ch) for range os.Args[1:] 
{ }  go fetch(url, ch) for _, url := range os.Args[1:] { ch := make(chan 
string) start := time.Now()func main() 
{) "time" "os" "net/http" "io/ioutil" "io" "fmt"import (

-- 
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: Bulky (Payload) Structs in API

[dc0d]

Thanks!

The bot package was just an example. This is a general concern IMHO. 
Interfaces do nicely when we want to hide implementation details (on 
accepting things as an interface). For example package A is a low-level, 
infrastructure package at Infrastructure layer/area. Now at the Interfaces 
layer, the package B is placed, which provides a nice set of abstractions 
for package A. In a use-case package named C, those abstractions from 
package B is used.

So far, so good! Now, as explained, package A has those bulky fat payloads; 
which forces us to use package A, directly inside package C.

This nullifies the purpose of package B.

This indeed, happens when a generic bot is being implemented. But even if 
that was not the case, I failed to find a way to prevent A from leaking 
into C.

At the end of the day it's all about trade-offs! I think you are right that 
there is no other way around and we have to either use A directly or write 
a translation layer.

Yet I'm curious about using type aliases as (yet another level of) an 
indirection.

On Monday, November 13, 2017 at 12:00:27 PM UTC+3:30, Egon wrote:
>
> Is there a problem created from sharing the package or creating a separate 
> package? Or why is that dependency a problem?
>
> There's some knowledge about the requests/responses shared between 
> packages. Trying to hide it, doesn't gain anything -- it only makes the 
> sharing implicit rather than explicit.
>
> When you are writing a "telegram-bot" you should know the request/response.
>
> However, when you are writing a "generic-bot" that works with "telegram" 
> then the solution is to implement some sort of translation layer and 
> provide a minimal API for the "generic-bot".
>
> In the end -- you will either have some shared artifact or a translation 
> layer. I see no way of escaping it.
>
> + Egon
>
> On Monday, 13 November 2017 09:48:07 UTC+2, dc0d wrote:
>>
>> Thanks!
>>
>> That's what I do, though not happy with it. I had to write some helper 
>> apps and scripts (I'm not fluent in playing with Go ast yet).
>>
>> An example would be the API to Telegram Bot (package 
>> ). Requests and 
>> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
>> Go structs are the one in question.
>>
>> As it can be seen, they are pretty big and bulky (can not be helped, it's 
>> how the Telegram API is). But passing them up/out, makes other packages, 
>> become dependent on *tgbotapi* package.
>>
>> As for functionality, interfaces work great. But for payloads that are 
>> being passed between packages (even if they are POGOs) I can not find a 
>> clean approach for sharing them.
>>
>> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>>
>>> One possibility is copy-paste the structure and convert at call 
>>> boundaries.
>>>
>>> https://play.golang.org/p/5LFw6U3yi6
>>>
>>> But, can you show a real-world example to ground the conversation?
>>>
>>> + Egon
>>>
>>> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:

 It is a Go best practice to "accept interfaces, return concrete types". 
 Which helps greatly in implementing different architectures/designs (like 
 Clean Architecture or the like).

 There are times that a package is used which returns fat structs (as 
 the concrete type) - mostly POGO.

 Problem:
 Redefining some domain models for those payloads is cumbersome and 
 sometimes impractical. At the same time using them directly, exposes other 
 packages to that package that we want to abstract out it's functionality. 
 Some unwelcome dependency.

 Question:
 Should we redefined all those data types in upper layers for using 
 them? If no what is the solution?

>>>

-- 
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: Bulky (Payload) Structs in API

[Egon]

Is there a problem created from sharing the package or creating a separate 
package? Or why is that dependency a problem?

There's some knowledge about the requests/responses shared between 
packages. Trying to hide it, doesn't gain anything -- it only makes the 
sharing implicit rather than explicit.

When you are writing a "telegram-bot" you should know the request/response.

However, when you are writing a "generic-bot" that works with "telegram" 
then the solution is to implement some sort of translation layer and 
provide a minimal API for the "generic-bot".

In the end -- you will either have some shared artifact or a translation 
layer. I see no way of escaping it.

+ Egon

On Monday, 13 November 2017 09:48:07 UTC+2, dc0d wrote:
>
> Thanks!
>
> That's what I do, though not happy with it. I had to write some helper 
> apps and scripts (I'm not fluent in playing with Go ast yet).
>
> An example would be the API to Telegram Bot (package 
> ). Requests and 
> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
> Go structs are the one in question.
>
> As it can be seen, they are pretty big and bulky (can not be helped, it's 
> how the Telegram API is). But passing them up/out, makes other packages, 
> become dependent on *tgbotapi* package.
>
> As for functionality, interfaces work great. But for payloads that are 
> being passed between packages (even if they are POGOs) I can not find a 
> clean approach for sharing them.
>
> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>
>> One possibility is copy-paste the structure and convert at call 
>> boundaries.
>>
>> https://play.golang.org/p/5LFw6U3yi6
>>
>> But, can you show a real-world example to ground the conversation?
>>
>> + Egon
>>
>> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>>>
>>> It is a Go best practice to "accept interfaces, return concrete types". 
>>> Which helps greatly in implementing different architectures/designs (like 
>>> Clean Architecture or the like).
>>>
>>> There are times that a package is used which returns fat structs (as the 
>>> concrete type) - mostly POGO.
>>>
>>> Problem:
>>> Redefining some domain models for those payloads is cumbersome and 
>>> sometimes impractical. At the same time using them directly, exposes other 
>>> packages to that package that we want to abstract out it's functionality. 
>>> Some unwelcome dependency.
>>>
>>> Question:
>>> Should we redefined all those data types in upper layers for using them? 
>>> If no what is the solution?
>>>
>>

-- 
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] pprof implementation concepts

[dmitri]

I've put together a blog post explaining the implementation concepts behind 
CPU, allocation and block profilers.

It is not as detailed as some of the original articles, but hopefully 
useful to pprof users in terms of better understanding what to expect from 
the data.

https://stackimpact.com/blog/go-profiler-internals/

Any feedback on possible inconsistencies with implementation is very much 
appreciated.

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