[go-nuts] input and output about go

[2891132love]

  I am a beginning learner.there is a simple question about go,the program 
is in the following:
package main

import (
 "bufio"
 "fmt"
 "os"
)
func main() {
 
 counts := make(map[string]int)
 input := bufio.NewScanner(os.Stdin)
 for input.Scan() {
  counts[input.Text()]++
 }
 for line, n := range counts {
  if n > 1 {
   fmt.Println("%d\t%s\n", n, line)
  }
 }
}

the question is how I input the number and get the output result??

-- 
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: append to a stem racy?

[Egon]

Yes, that is indeed a race: https://play.golang.org/p/JH6dx9UNxm

But it only happens when there are multiple cases where:

len(stem) + len(tail) < cap(stem)

race-detector detects unsynchronized write-then-(write|read)-s to a memory 
location

For example when there is only one case for "len(stem) + len(tail) < 
cap(stem)" -- it will work, because the unused buffer in "stem" is written, 
but it is read from the same goroutine.

Although, it probably should throw a race warning all the time
i.e. implementation-wise it probably should do:

func append(xs []int, data ...int) []int {
if race.Enabled && len(xs) < cap(xs) {
xs[len(xs)] = 0
}
// actual append implementation
}

On Monday, 6 November 2017 02:44:11 UTC+2, kortschak wrote:
>
> Say I have a []T that I want to use as a common stem that has a tail 
> appended onto it, used concurrently, for example: 
>
> for i := 0; i < N; i++ { 
> tail := makeTail(i) // Returns a []T. 
> wg.Add(1) 
> go func() { 
> defer wg.Done() 
> a := append(stem, tail...) 
> fn(a) // Does something expensive with a []T. 
> }() 
> } 
> wg.Wait() 
>
> This looks racy to me, since each append can potentially clobber 
> elements in stem between len(stem) and cap(stem). Am I being paranoid 
> or should I write this append as append(stem[:len(stem):len(stem)], 
> tail...)? 
>
> I have not been able to get the race detector to complain about this, 
> even if I make len << cap. 
>
> thanks 
>

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

Re: [go-nuts] Rationale in docs on why you need to use the result of append()

[Christoph Berger]

This describes pretty clearly what happens behind the scenes. 

Still, someone could wonder why append then does not receive a pointer to 
the slice, to ensure that both the slice header and the slice data are 
treated in a consistent way. 

What is the generally accepted answer to this? For example,

* In/out parameters are bad coding style
* append shall have a function signature similar to other standard 
functions, for example, fmt.Sprintf (that also returns its result, rather 
than updating a pointer parameter)
* or some technical reason


On Monday, November 6, 2017 at 3:24:55 AM UTC+1, Dave Cheney wrote:
>
> I think #1 would be clearer if it were written as 
>
> 1) "We must return the slice afterwards because ... the our slice value 
> (the run-time data structure holding the pointer, length, and capacity) is 
> a copy of the callers.”

-- 
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: input and output about go

[Karan Chaudhary]

You need to break the scanning by passing EOF to the program.  Use ctrl-d 
if you're on Unix based system.

go doc bufio.Scan
func (s *Scanner) Scan() bool
Scan advances the Scanner to the next token, which will then be 
available
through the Bytes or Text method. It returns false when the scan stops,
either by reaching the end of the input or an error. After Scan returns
false, the Err method will return any error that occurred during 
scanning,
except that if it was io.EOF, Err will return nil. Scan panics if the 
split
function returns 100 empty tokens without advancing the input. This is a
common error mode for scanners.



PS:  
1. Use fmt.Printf rather than fmt.Println to print output.
2. While posting code,  do format the code as its easier to read.

On Monday, 6 November 2017 13:29:58 UTC+5:30, 28911...@gmail.com wrote:
>
>   I am a beginning learner.there is a simple question about go,the program 
> is in the following:
> package main
>
> import (
>  "bufio"
>  "fmt"
>  "os"
> )
> func main() {
>  
>  counts := make(map[string]int)
>  input := bufio.NewScanner(os.Stdin)
>  for input.Scan() {
>   counts[input.Text()]++
>  }
>  for line, n := range counts {
>   if n > 1 {
>fmt.Println("%d\t%s\n", n, line)
>   }
>  }
> }
>
> the question is how I input the number and get the output result??
>

-- 
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] network programming about go

[roger peppe]

On 30 October 2017 at 06:55,  <2891132l...@gmail.com> wrote:
> I write this code in the follwings:
> package main
>
> import (
> "fmt"
> "net"
> "os"
> )
>
> func main() {
> service := ":5000"
> tcpAddr, err := net.ResolveTCPAddr("tcp", service)
> checkError(err)
> listener, err := net.ListenTCP("tcp", tcpAddr)
> 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]))
> _, err2 := conn.Write([]byte("welcome client!"))
> if err2 != nil {
> return
> }
> }
> }
> func checkError(err error) {
> if err != nil {
> fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
> os.Exit(1)
> }
> }
>
>
> I try to run it in Sublime Text3 but it has no reaction and I try to run it
> in running windows, it shows:
> fatal error: lsiten tcp:5000:bind:Only one usage of each socket
> address(protocol/network address/port) is normally permitted.exit status 1

>From that error message, I suspect that you already have a running instance
of your program - as the message says, you are only allowed to listen
on a port once.

To avoid that, you could listen on port zero, which will choose an arbitrary
port (but then you'll need to print out the port number so that you can
know which port to use on the client).

By the way, your code is a little bit more complex than
it needs to be. Instead of this:

> service := ":5000"
> tcpAddr, err := net.ResolveTCPAddr("tcp", service)
> checkError(err)
> listener, err := net.ListenTCP("tcp", tcpAddr)

You could do:

service := ":5000"
listener, err := net.Listen("tcp", tcpAddr)

Similarly when dialing - there's no need to call ResolveTCPAddr
explicitly (and it's actually not as good if you do that,
because Dial will automatically use multiple IP addresses
if it needs to, but if you use ResolveTCPAddr, it can only use one).

Hope this helps,

  rog.

-- 
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: concurrency programing about go

[Christoph Berger]

Always call Add() before spawning the corresponding goroutine(s). And 
always call Add() in the same goroutine that also calls Wait(). This way 
you have no race condition between Add(), Done(), and Wait().


On Saturday, November 4, 2017 at 10:46:21 AM UTC+1, Henrik Johansson wrote:
>
> I find continuously adding and calling done on a waitgroup a bit odd. The 
> waiting goroutine can continue as soon as the count is zero so there is  a 
> race between adds and dones. 
>
> On Sat, 4 Nov 2017, 10:01 , <28911...@gmail.com > wrote:
>
>> Thank you very much.Sorry I still have some question:what's the function 
>> of wg? what does the sentense "wg.Add(2) " mean?? I found that if I change 
>> 2 into 1,the result is differnet.
>>
>> 在 2017年11月3日星期五 UTC+8上午4:45:47，snmed写道：
>>
>>> Hi 
>>>
>>> Here is the code:
>>>
>>> Version 1:
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "sync"
>>> )
>>>
>>> var a string
>>> var once sync.Once
>>>
>>> func setup() {
>>> a = "hello,world\n"
>>> }
>>> func doprint() {
>>> once.Do(setup)
>>> fmt.Print(a)
>>> }
>>> func twoprint() <-chan struct{} {
>>> var wg sync.WaitGroup
>>> wg.Add(2)
>>> ch := make(chan struct{})
>>>
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>>
>>> go func() {
>>> wg.Wait()
>>> close(ch)
>>> }()
>>>
>>> return ch
>>> }
>>>
>>> func main() {
>>> ch := twoprint()
>>> <-ch
>>> }
>>>
>>>
>>> Version 2:
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "sync"
>>> )
>>>
>>> var a string
>>> var once sync.Once
>>>
>>> func setup() {
>>> a = "hello,world\n"
>>> }
>>> func doprint() {
>>> once.Do(setup)
>>> fmt.Print(a)
>>> }
>>> func twoprint() {
>>> var wg sync.WaitGroup
>>> wg.Add(2)
>>>
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>>
>>> wg.Wait()
>>> }
>>>
>>> func main() {
>>> twoprint()
>>> }
>>>
>>>
>>> Cheers snmed
>>>
>>>
>>> Am Donnerstag, 2. November 2017 10:37:15 UTC+1 schrieb 
>>> 28911...@gmail.com:

 Sorry,I try my best to open the website but it can't work.Can you write 
 it ??Thank you so much.

 在 2017年10月30日星期一 UTC+8下午4:29:44，snmed写道：
>
> Hi
>
> There are several ways to solve it, here are two of them:
>
> https://play.golang.org/p/wJwkI7HQwv
> https://play.golang.org/p/nasUcgBeG4
>
> I prefer the first one, because so I can decide if i want to wait for 
> the end of twoprint or not.
>
> Cheers
>
> Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com:
>>
>> Yes, you're right.So how to solve it??
>>
>> 在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：
>>>
>>> Hello. I’m guessing that your tried calling twoprint(), but you’ve 
>>> probably found that nothing is printed to the screen before your 
>>> program 
>>> exits. 
>>>
>>> Is that correct?
>>
>> -- 
>> 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] Go for Data science Blogs

[Vikram Rawat]

Is there any blog where we can start to learn Data analytics in GO. has 
anybody started a blog in GO. where we can learn basic data manupulation 
with go.

-- 
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: concurrency programing about go

[Karan Chaudhary]

Just a note that waitGroup should be passed as reference to 
functions/methods rather than as value.  I have made mistakes where the 
program hung as Done was called on copy of waitgroup rather than on the 
original wg to which tasks were added.

Here it is not a problem as waitgroup used within anon functions is taken 
from scope.

-- 
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: concurrency programing about go

[Henrik Johansson]

Indeed this is what I do but I learned the hard way and often it comes up
as "safe" in the mailing list to not do so but while true from a memory
model perspective it is, I would say, wrong to do so.

mån 6 nov. 2017 kl 10:39 skrev Christoph Berger <
christoph.g.ber...@gmail.com>:

> Always call Add() before spawning the corresponding goroutine(s). And
> always call Add() in the same goroutine that also calls Wait(). This way
> you have no race condition between Add(), Done(), and Wait().
>
>
> On Saturday, November 4, 2017 at 10:46:21 AM UTC+1, Henrik Johansson wrote:
>
>> I find continuously adding and calling done on a waitgroup a bit odd. The
>> waiting goroutine can continue as soon as the count is zero so there is  a
>> race between adds and dones.
>>
>> On Sat, 4 Nov 2017, 10:01 , <28911...@gmail.com> wrote:
>>
> Thank you very much.Sorry I still have some question:what's the function
>>> of wg? what does the sentense "wg.Add(2) " mean?? I found that if I change
>>> 2 into 1,the result is differnet.
>>>
>>> 在 2017年11月3日星期五 UTC+8上午4:45:47，snmed写道：
>>>
 Hi

 Here is the code:

 Version 1:
 package main

 import (
 "fmt"
 "sync"
 )

 var a string
 var once sync.Once

 func setup() {
 a = "hello,world\n"
 }
 func doprint() {
 once.Do(setup)
 fmt.Print(a)
 }
 func twoprint() <-chan struct{} {
 var wg sync.WaitGroup
 wg.Add(2)
 ch := make(chan struct{})

 go func() {
 doprint()
 wg.Done()
 }()
 go func() {
 doprint()
 wg.Done()
 }()

 go func() {
 wg.Wait()
 close(ch)
 }()

 return ch
 }

 func main() {
 ch := twoprint()
 <-ch
 }


 Version 2:
 package main

 import (
 "fmt"
 "sync"
 )

 var a string
 var once sync.Once

 func setup() {
 a = "hello,world\n"
 }
 func doprint() {
 once.Do(setup)
 fmt.Print(a)
 }
 func twoprint() {
 var wg sync.WaitGroup
 wg.Add(2)

 go func() {
 doprint()
 wg.Done()
 }()
 go func() {
 doprint()
 wg.Done()
 }()

 wg.Wait()
 }

 func main() {
 twoprint()
 }


 Cheers snmed


 Am Donnerstag, 2. November 2017 10:37:15 UTC+1 schrieb
 28911...@gmail.com:
>
> Sorry,I try my best to open the website but it can't work.Can you
> write it ??Thank you so much.
>
> 在 2017年10月30日星期一 UTC+8下午4:29:44，snmed写道：
>>
>> Hi
>>
>> There are several ways to solve it, here are two of them:
>>
>> https://play.golang.org/p/wJwkI7HQwv
>> https://play.golang.org/p/nasUcgBeG4
>>
>> I prefer the first one, because so I can decide if i want to wait for
>> the end of twoprint or not.
>>
>> Cheers
>>
>> Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com
>> :
>>>
>>> Yes, you're right.So how to solve it??
>>>
>>> 在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：

 Hello. I’m guessing that your tried calling twoprint(), but you’ve
 probably found that nothing is printed to the screen before your 
 program
 exits.

 Is that correct?
>>>
>>> --
>>> 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] Bizarre Error Message (Go 1.9.2)

[Karan Chaudhary]

>
> `go run` takes multiple files as arguments. 
>

Interesting.  Didn't know this was possible.  Until now i used to fallback 
to using go build if code was distributed over multiple files. (When i'm 
testing some case which includes few files) 

-- 
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 could a new user konw which packge should be used?

[Karan Chaudhary]

Another one: http://go-search.org

On Friday, 3 November 2017 21:21:48 UTC+5:30, 517 March wrote:
>
> as a new Go programmer， 
> how could I know which package should be use？
>
> is there any search tool could be used？
>
> or does it just depend on your  experience？
>

-- 
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 for Data science Blogs

[Sebastien Binet]

Hi,

I would start with:

- gonum.org
- gopherdata.io

I have also started a little series about how to apply Go and Gonum to
stats (in high energy physics but that's just the setup)
sbinet.github.io

/shameless-plug off.

hth,
-s


sent from my droid

On Nov 6, 2017 10:46 AM, "Vikram Rawat"  wrote:

> Is there any blog where we can start to learn Data analytics in GO. has
> anybody started a blog in GO. where we can learn basic data manupulation
> with go.
>
> --
> 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 could a new user konw which packge should be used?

[djadala]

On Monday, November 6, 2017 at 12:23:37 PM UTC+2, Karan Chaudhary wrote:
>
> Another one: http://go-search.org
>

Go Search 
756881  golang packages in 171083 projects 
indexed, last updated 265 days ago.

265 days ago. ???
No, thanks.

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

[go-nuts] Re: Passing a string

[Chun Zhang]

Hi, 

Thank you for the reply! 

The C libi.PI_init_global_config has the interface of 
PI_init_global_config(int argc, char *argv[]);
so Swig converts it to PI_init_global_config(arg1 int, arg2 *string)

The code was expecting to a *string. Viper.GetString returns a string as 
far as I can see, is that right? So device is a string, not a *string. 
(verified with reflect.TypeOf). Everything matches except for the crash :(

What really puzzles me is that why when passing the parameter using flag is 
fine, as well as when hard-coding the value. In both cases, device is still 
a string, nothing changed. But whenever trying to read the value from a 
config file using viper or just simple json.decoder, the code complains it 
is a pointer to a pointer. I mean, I literally did a comparison between the 
read-in value and a variable hard-coded as "eth1", it says they are equal. 

Best,
Chun





On Monday, November 6, 2017 at 1:07:46 AM UTC-5, Tamás Gulácsi wrote:
>
>
> 2017. november 6., hétfő 2:11:48 UTC+1 időpontban Chun Zhang a következőt 
> írta:
>>
>> Hi, All, 
>>
>> I am trying to read a configuration file using Viper, the config file is 
>> a very simple json file with one line
>> {
>> "device" : "eth1"
>> }
>>
>> I use the following line to read it 
>>
>> device := viper.GetString("device")
>>
>>
>> then passing this var further into a C library with swig generated api as 
>> arg2
>>
>> itc := device //Need to update if there is more devices
>> libpi.PI_init_global_config(1, &itc)
>>
>> func PI_init_global_config(arg1 int, arg2 *string) {
>>
>>
>>
>> I can retrieve the correct value,  and can verify that var device does 
>> have eth1 as the value when printf it.  I even did the compare of device == 
>> "eth1", and the result is true. 
>>
>> However, when passing this device var to the PI_init_gloable_config API, 
>> I got code crashed with the following error
>>
>> *panic: runtime error: cgo argument has Go pointer to Go pointer*
>>
>>
>
> The value you pass to C must not have a pointer which points to a Go 
> pointer. 
> What are you passing to  libpi.PI_init_global_config ?
> I think "device" is already a *string, so &itc is a **string - try 
> libpi.PI_init_global_config(device).
>
> (I assume libpi does some conversion, as the proper way to pass a string 
> ot C (*char) is to convert the string to *char with cs:=C.CString(*device) 
> and later C.free(unsafe.Pointer(cs)) it).
>
>>
>> If instead of reading this file from configuration json, I hardcode it in 
>> the code as 
>>
>> device := "eth1"
>>
>> then there is no issue at all. If I read this variable using Flag from 
>> command line, like
>>
>> flag.StringVar(&device, "Device", "eth1", "NIC to Listen")
>>
>>
>> there was no problem either. 
>>
>>
>>
>> Can anybody please enlighten me what's the difference? Why this error is 
>> triggered? I googled quite a bit, but it does not seem to help. I have go 
>> 1.8.3 installed.
>>
>> Thanks,
>> Chun
>>
>

-- 
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] accept4: too many open files;

[Karan Chaudhary]

CMIIW, I doubt if it is explicitly needed to close the request's body in 
handler,  as it seems,  close of request's body is handled by stdlib upon 
completion of handler.

Handler,  in net/http,  is called 
here: https://github.com/golang/go/blob/master/src/net/http/server.go#L1804
Finish 
Request: https://github.com/golang/go/blob/master/src/net/http/server.go#L1804
Request's body is closed 
here: https://github.com/golang/go/blob/master/src/net/http/server.go#L1525

Though,  HTTP response's body should be closed explicitly for connection 
reuse and stuff.

On Wednesday, 18 October 2017 01:34:35 UTC+5:30, Lee Armstrong wrote:
>
> This is 1.9.1 and I had not thought of switching to http2 although do need 
> to maintain the 1.1 for older clients. 
>
> The closing of the body could explain it though which I thought was 
> automatic on a return from the handlers? Do I need to explicitly call that 
> in the handlers??

-- 
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 could a new user konw which packge should be used?

[Karan Chaudhary]

Oh,  didn't check that!

On Monday, 6 November 2017 17:49:52 UTC+5:30, dja...@gmail.com wrote:
>
>
>
> On Monday, November 6, 2017 at 12:23:37 PM UTC+2, Karan Chaudhary wrote:
>>
>> Another one: http://go-search.org
>>
>
> Go Search 
>
756881  golang packages in 171083 projects 
> indexed, last updated 265 days ago.
>
> 265 days ago. ???
> No, thanks.
>
>

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

Re: [go-nuts] network programming about go

[2891132love]

I try to modify the program,but the result is: host:portfatal error: dial 
tcp 192.168.153.239:5000: connectex: No connection could be made because 
the target machine actively refused it.exit status 1.How to solve it??

在 2017年11月6日星期一 UTC+8下午5:08:26，rog写道：

> On 30 October 2017 at 06:55,  <28911...@gmail.com > wrote: 
> > I write this code in the follwings: 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "net" 
> > "os" 
> > ) 
> > 
> > func main() { 
> > service := ":5000" 
> > tcpAddr, err := net.ResolveTCPAddr("tcp", service) 
> > checkError(err) 
> > listener, err := net.ListenTCP("tcp", tcpAddr) 
> > 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])) 
> > _, err2 := conn.Write([]byte("welcome client!")) 
> > if err2 != nil { 
> > return 
> > } 
> > } 
> > } 
> > func checkError(err error) { 
> > if err != nil { 
> > fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error()) 
> > os.Exit(1) 
> > } 
> > } 
> > 
> > 
> > I try to run it in Sublime Text3 but it has no reaction and I try to run 
> it 
> > in running windows, it shows: 
> > fatal error: lsiten tcp:5000:bind:Only one usage of each socket 
> > address(protocol/network address/port) is normally permitted.exit status 
> 1 
>
> From that error message, I suspect that you already have a running 
> instance 
> of your program - as the message says, you are only allowed to listen 
> on a port once. 
>
> To avoid that, you could listen on port zero, which will choose an 
> arbitrary 
> port (but then you'll need to print out the port number so that you can 
> know which port to use on the client). 
>
> By the way, your code is a little bit more complex than 
> it needs to be. Instead of this: 
>
> > service := ":5000" 
> > tcpAddr, err := net.ResolveTCPAddr("tcp", service) 
> > checkError(err) 
> > listener, err := net.ListenTCP("tcp", tcpAddr) 
>
> You could do: 
>
> service := ":5000" 
> listener, err := net.Listen("tcp", tcpAddr) 
>
> Similarly when dialing - there's no need to call ResolveTCPAddr 
> explicitly (and it's actually not as good if you do that, 
> because Dial will automatically use multiple IP addresses 
> if it needs to, but if you use ResolveTCPAddr, it can only use one). 
>
> Hope this helps, 
>
>   rog. 
>

-- 
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] Urgent: race condition with ticker channels

[arunabh . arnav]

Hi,

I am fairly new to Golang, so please excuse if this is a silly question. I 
could not find any answers on the web.

Code portion A:

  rf.mu.Lock()
  rf.electionTicker =  time.NewTicker(rf.currentTimeout)  

Re: [go-nuts] Urgent: race condition with ticker channels

[Ian Davis]

On Mon, 6 Nov 2017, at 12:14 PM, arunabh.ar...@gmail.com wrote:
> Hi,
> 
> I am fairly new to Golang, so please excuse if this is a silly
> question. I could not find any answers on the web.> 
> Code portion A:
> 
>   rf.mu.Lock()
>   rf.electionTicker =  time.NewTicker(rf.currentTimeout)
>      rf.mu.Unlock()
> 
> Code portion B:
> for {
>   select {
> case <-rf.electionTicker.C: // do something
>  default:
>   }
> }
> 
> Can you please tell me why a channel read is facing a race condition.> Is 
> there a way to prevent this race?

The race is caused because you are writing to rf.electionTicker and then
reading from it to access the channel you want to read from. The channel
read itself is not causing the race.
You could read rf.electionTicker into a variable in some code guarded by
the mutex and read from that instead.

Ian

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

[go-nuts] goto from inner select

[djadala]

Hi all,
Can someone explain, is this program  is really incorrect:
https://play.golang.org/p/0fp9Nt_99L

trying to run it results in error:
tmp/sandbox536393528/main.go:16:9: goto C jumps into block starting at 
tmp/sandbox536393528/main.go:10:2
but goto jumps in outside block.

I trying to make priority select by nesting selects, and want to find way 
to write logic only in one place.

Regards,
Jamil Djadala

-- 
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] goto from inner select

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 8:55 AM,   wrote:
>
> Can someone explain, is this program  is really incorrect:
> https://play.golang.org/p/0fp9Nt_99L
>
> trying to run it results in error:
> tmp/sandbox536393528/main.go:16:9: goto C jumps into block starting at
> tmp/sandbox536393528/main.go:10:2
> but goto jumps in outside block.

Every case in a switch is an implicit block, so, yes, this program is
invalid and the compiler is telling you why.


> I trying to make priority select by nesting selects, and want to find way to
> write logic only in one place.

Use a function?

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] Re: Passing a string

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 4:25 AM, Chun Zhang  wrote:
>
> Thank you for the reply!
>
> The C libi.PI_init_global_config has the interface of
> PI_init_global_config(int argc, char *argv[]);
> so Swig converts it to PI_init_global_config(arg1 int, arg2 *string)
>
> The code was expecting to a *string. Viper.GetString returns a string as far
> as I can see, is that right? So device is a string, not a *string. (verified
> with reflect.TypeOf). Everything matches except for the crash :(
>
> What really puzzles me is that why when passing the parameter using flag is
> fine, as well as when hard-coding the value. In both cases, device is still
> a string, nothing changed. But whenever trying to read the value from a
> config file using viper or just simple json.decoder, the code complains it
> is a pointer to a pointer. I mean, I literally did a comparison between the
> read-in value and a variable hard-coded as "eth1", it says they are equal.

A Go string contains an internal pointer.  Passing a *string to cgo
means that you are passing a pointer to a string that contains a
pointer, so you are passing a pointer to a pointer.  That is invalid
according to the cgo pointer passing rules.

A Go string is definitely not a C or C++ string.  You can not pass a
pointer to a Go string to C code that expects a char**.  Even if cgo
permitted it, it would not work.  If SWIG is converting a C char** (or
char*[]) to Go *string, then SWIG is getting it wrong.

Ian


> On Monday, November 6, 2017 at 1:07:46 AM UTC-5, Tamás Gulácsi wrote:
>>
>>
>> 2017. november 6., hétfő 2:11:48 UTC+1 időpontban Chun Zhang a következőt
>> írta:
>>>
>>> Hi, All,
>>>
>>> I am trying to read a configuration file using Viper, the config file is
>>> a very simple json file with one line
>>> {
>>> "device" : "eth1"
>>> }
>>>
>>> I use the following line to read it
>>>
>>> device := viper.GetString("device")
>>>
>>>
>>> then passing this var further into a C library with swig generated api as
>>> arg2
>>>
>>> itc := device //Need to update if there is more devices
>>> libpi.PI_init_global_config(1, &itc)
>>>
>>> func PI_init_global_config(arg1 int, arg2 *string) {
>>>
>>>
>>>
>>> I can retrieve the correct value,  and can verify that var device does
>>> have eth1 as the value when printf it.  I even did the compare of device ==
>>> "eth1", and the result is true.
>>>
>>> However, when passing this device var to the PI_init_gloable_config API,
>>> I got code crashed with the following error
>>>
>>> panic: runtime error: cgo argument has Go pointer to Go pointer
>>>
>>
>>
>> The value you pass to C must not have a pointer which points to a Go
>> pointer.
>> What are you passing to  libpi.PI_init_global_config ?
>> I think "device" is already a *string, so &itc is a **string - try
>> libpi.PI_init_global_config(device).
>>
>> (I assume libpi does some conversion, as the proper way to pass a string
>> ot C (*char) is to convert the string to *char with cs:=C.CString(*device)
>> and later C.free(unsafe.Pointer(cs)) it).
>>>
>>>
>>> If instead of reading this file from configuration json, I hardcode it in
>>> the code as
>>>
>>> device := "eth1"
>>>
>>> then there is no issue at all. If I read this variable using Flag from
>>> command line, like
>>>
>>> flag.StringVar(&device, "Device", "eth1", "NIC to Listen")
>>>
>>>
>>> there was no problem either.
>>>
>>>
>>>
>>> Can anybody please enlighten me what's the difference? Why this error is
>>> triggered? I googled quite a bit, but it does not seem to help. I have go
>>> 1.8.3 installed.
>>>
>>> Thanks,
>>> Chun
>
> --
> 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] goto from inner select

[djadala]

On Monday, November 6, 2017 at 8:03:28 PM UTC+2, Ian Lance Taylor wrote:
>
> On Mon, Nov 6, 2017 at 8:55 AM,  > wrote: 
> > 
> > Can someone explain, is this program  is really incorrect: 
> > https://play.golang.org/p/0fp9Nt_99L 
> > 
> > trying to run it results in error: 
> > tmp/sandbox536393528/main.go:16:9: goto C jumps into block starting at 
> > tmp/sandbox536393528/main.go:10:2 
> > but goto jumps in outside block. 
>
> Every case in a switch is an implicit block, so, yes, this program is 
> invalid and the compiler is telling you why. 
>

Thanks for clear explanation
 

>
> > I trying to make priority select by nesting selects, and want to find 
> way to 
> > write logic only in one place. 
>
> Use a function? 


Yes, i consider using functions, just wonder why goto does not work,

Thanks again.

Jamil Djadala



 

-- 
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: Passing a string

[Chun Zhang]

Thank you Ian!! That does make sense.

Can you please elaborate why hardcoding device = "eth1" works? What is the
difference here?

Sincerely,
Chun

On Mon, Nov 6, 2017 at 1:19 PM, Ian Lance Taylor  wrote:

> On Mon, Nov 6, 2017 at 4:25 AM, Chun Zhang  wrote:
> >
> > Thank you for the reply!
> >
> > The C libi.PI_init_global_config has the interface of
> > PI_init_global_config(int argc, char *argv[]);
> > so Swig converts it to PI_init_global_config(arg1 int, arg2 *string)
> >
> > The code was expecting to a *string. Viper.GetString returns a string as
> far
> > as I can see, is that right? So device is a string, not a *string.
> (verified
> > with reflect.TypeOf). Everything matches except for the crash :(
> >
> > What really puzzles me is that why when passing the parameter using flag
> is
> > fine, as well as when hard-coding the value. In both cases, device is
> still
> > a string, nothing changed. But whenever trying to read the value from a
> > config file using viper or just simple json.decoder, the code complains
> it
> > is a pointer to a pointer. I mean, I literally did a comparison between
> the
> > read-in value and a variable hard-coded as "eth1", it says they are
> equal.
>
> A Go string contains an internal pointer.  Passing a *string to cgo
> means that you are passing a pointer to a string that contains a
> pointer, so you are passing a pointer to a pointer.  That is invalid
> according to the cgo pointer passing rules.
>
> A Go string is definitely not a C or C++ string.  You can not pass a
> pointer to a Go string to C code that expects a char**.  Even if cgo
> permitted it, it would not work.  If SWIG is converting a C char** (or
> char*[]) to Go *string, then SWIG is getting it wrong.
>
> Ian
>
>
> > On Monday, November 6, 2017 at 1:07:46 AM UTC-5, Tamás Gulácsi wrote:
> >>
> >>
> >> 2017. november 6., hétfő 2:11:48 UTC+1 időpontban Chun Zhang a
> következőt
> >> írta:
> >>>
> >>> Hi, All,
> >>>
> >>> I am trying to read a configuration file using Viper, the config file
> is
> >>> a very simple json file with one line
> >>> {
> >>> "device" : "eth1"
> >>> }
> >>>
> >>> I use the following line to read it
> >>>
> >>> device := viper.GetString("device")
> >>>
> >>>
> >>> then passing this var further into a C library with swig generated api
> as
> >>> arg2
> >>>
> >>> itc := device //Need to update if there is more devices
> >>> libpi.PI_init_global_config(1, &itc)
> >>>
> >>> func PI_init_global_config(arg1 int, arg2 *string) {
> >>>
> >>>
> >>>
> >>> I can retrieve the correct value,  and can verify that var device does
> >>> have eth1 as the value when printf it.  I even did the compare of
> device ==
> >>> "eth1", and the result is true.
> >>>
> >>> However, when passing this device var to the PI_init_gloable_config
> API,
> >>> I got code crashed with the following error
> >>>
> >>> panic: runtime error: cgo argument has Go pointer to Go pointer
> >>>
> >>
> >>
> >> The value you pass to C must not have a pointer which points to a Go
> >> pointer.
> >> What are you passing to  libpi.PI_init_global_config ?
> >> I think "device" is already a *string, so &itc is a **string - try
> >> libpi.PI_init_global_config(device).
> >>
> >> (I assume libpi does some conversion, as the proper way to pass a string
> >> ot C (*char) is to convert the string to *char with
> cs:=C.CString(*device)
> >> and later C.free(unsafe.Pointer(cs)) it).
> >>>
> >>>
> >>> If instead of reading this file from configuration json, I hardcode it
> in
> >>> the code as
> >>>
> >>> device := "eth1"
> >>>
> >>> then there is no issue at all. If I read this variable using Flag from
> >>> command line, like
> >>>
> >>> flag.StringVar(&device, "Device", "eth1", "NIC to Listen")
> >>>
> >>>
> >>> there was no problem either.
> >>>
> >>>
> >>>
> >>> Can anybody please enlighten me what's the difference? Why this error
> is
> >>> triggered? I googled quite a bit, but it does not seem to help. I have
> go
> >>> 1.8.3 installed.
> >>>
> >>> Thanks,
> >>> Chun
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Passing a string

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 10:29 AM, Chun Zhang  wrote:
> Thank you Ian!! That does make sense.
>
> Can you please elaborate why hardcoding device = "eth1" works? What is the
> difference here?

I'm sorry, I'm not sure I really understand the question.  The pointer
passing rules apply only when calling functions written in C rather
than Go.  When you write `device = "eth1"` there is no C function
involved.

Ian

> On Mon, Nov 6, 2017 at 1:19 PM, Ian Lance Taylor  wrote:
>>
>> On Mon, Nov 6, 2017 at 4:25 AM, Chun Zhang  wrote:
>> >
>> > Thank you for the reply!
>> >
>> > The C libi.PI_init_global_config has the interface of
>> > PI_init_global_config(int argc, char *argv[]);
>> > so Swig converts it to PI_init_global_config(arg1 int, arg2 *string)
>> >
>> > The code was expecting to a *string. Viper.GetString returns a string as
>> > far
>> > as I can see, is that right? So device is a string, not a *string.
>> > (verified
>> > with reflect.TypeOf). Everything matches except for the crash :(
>> >
>> > What really puzzles me is that why when passing the parameter using flag
>> > is
>> > fine, as well as when hard-coding the value. In both cases, device is
>> > still
>> > a string, nothing changed. But whenever trying to read the value from a
>> > config file using viper or just simple json.decoder, the code complains
>> > it
>> > is a pointer to a pointer. I mean, I literally did a comparison between
>> > the
>> > read-in value and a variable hard-coded as "eth1", it says they are
>> > equal.
>>
>> A Go string contains an internal pointer.  Passing a *string to cgo
>> means that you are passing a pointer to a string that contains a
>> pointer, so you are passing a pointer to a pointer.  That is invalid
>> according to the cgo pointer passing rules.
>>
>> A Go string is definitely not a C or C++ string.  You can not pass a
>> pointer to a Go string to C code that expects a char**.  Even if cgo
>> permitted it, it would not work.  If SWIG is converting a C char** (or
>> char*[]) to Go *string, then SWIG is getting it wrong.
>>
>> Ian
>>
>>
>> > On Monday, November 6, 2017 at 1:07:46 AM UTC-5, Tamás Gulácsi wrote:
>> >>
>> >>
>> >> 2017. november 6., hétfő 2:11:48 UTC+1 időpontban Chun Zhang a
>> >> következőt
>> >> írta:
>> >>>
>> >>> Hi, All,
>> >>>
>> >>> I am trying to read a configuration file using Viper, the config file
>> >>> is
>> >>> a very simple json file with one line
>> >>> {
>> >>> "device" : "eth1"
>> >>> }
>> >>>
>> >>> I use the following line to read it
>> >>>
>> >>> device := viper.GetString("device")
>> >>>
>> >>>
>> >>> then passing this var further into a C library with swig generated api
>> >>> as
>> >>> arg2
>> >>>
>> >>> itc := device //Need to update if there is more devices
>> >>> libpi.PI_init_global_config(1, &itc)
>> >>>
>> >>> func PI_init_global_config(arg1 int, arg2 *string) {
>> >>>
>> >>>
>> >>>
>> >>> I can retrieve the correct value,  and can verify that var device does
>> >>> have eth1 as the value when printf it.  I even did the compare of
>> >>> device ==
>> >>> "eth1", and the result is true.
>> >>>
>> >>> However, when passing this device var to the PI_init_gloable_config
>> >>> API,
>> >>> I got code crashed with the following error
>> >>>
>> >>> panic: runtime error: cgo argument has Go pointer to Go pointer
>> >>>
>> >>
>> >>
>> >> The value you pass to C must not have a pointer which points to a Go
>> >> pointer.
>> >> What are you passing to  libpi.PI_init_global_config ?
>> >> I think "device" is already a *string, so &itc is a **string - try
>> >> libpi.PI_init_global_config(device).
>> >>
>> >> (I assume libpi does some conversion, as the proper way to pass a
>> >> string
>> >> ot C (*char) is to convert the string to *char with
>> >> cs:=C.CString(*device)
>> >> and later C.free(unsafe.Pointer(cs)) it).
>> >>>
>> >>>
>> >>> If instead of reading this file from configuration json, I hardcode it
>> >>> in
>> >>> the code as
>> >>>
>> >>> device := "eth1"
>> >>>
>> >>> then there is no issue at all. If I read this variable using Flag from
>> >>> command line, like
>> >>>
>> >>> flag.StringVar(&device, "Device", "eth1", "NIC to Listen")
>> >>>
>> >>>
>> >>> there was no problem either.
>> >>>
>> >>>
>> >>>
>> >>> Can anybody please enlighten me what's the difference? Why this error
>> >>> is
>> >>> triggered? I googled quite a bit, but it does not seem to help. I have
>> >>> go
>> >>> 1.8.3 installed.
>> >>>
>> >>> Thanks,
>> >>> Chun
>> >
>> > --
>> > 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...@go

Re: [go-nuts] How to determine the correct method signature to override fopen

[tonywalker . uk]

In that case - do you know how I can inspect the comparison it's doing? 
Since I'm already doing this for the open system call, I know that it's 
possible to write a function with the same definition. It seems in this 
case that I'm not matching the representation that cgo is expecting. I 
would therefore like to see what cgo thing it looks like so I can attempt 
to get a perfect match. Would that be possible?

On Friday, November 3, 2017 at 11:50:36 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Nov 3, 2017 at 5:44 PM,  > 
> wrote: 
> > 
> > Thanks Ian. I had included that because it seems required in order for 
> me to 
> > refer to the return type (C.FILE) and so I can access the underlying 
> C.fopen 
> > function.  This is the approach I have with open but perhaps this is 
> > different. 
> > If I'm not supposed to use the include, can you advise how I should 
> refer to 
> > the type/function from the header? 
>
> I'm sorry, nothing comes to mind.  In C you would just write the 
> declaration the way the header file expects, but cgo doesn't provide a 
> way to do that. 
>
> Ian 
>
>
> > On Friday, November 3, 2017 at 8:28:38 PM UTC-4, Ian Lance Taylor wrote: 
> >> 
> >> On Fri, Nov 3, 2017 at 2:24 PM,   wrote: 
> >> > 
> >> > I've been writing a shared-object which I'll use via LD_PRELOAD to 
> >> > override 
> >> > the open syscall. This is currently working OK but now I want to move 
> on 
> >> > to 
> >> > fopen. I've defined it (as far as I can tell) in-line with the stdio 
> >> > header 
> >> > see here. However, when I try and build: 
> >> > 
> >> > $ go build -buildmode=c-shared 
> >> > # github.com/walkert/loader 
> >> > In file included from 
> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0: 
> >> > ./main.go:56:14: error: conflicting types for ‘fopen’ 
> >> > In file included from ./main.go:5:0, 
> >> >  from 
> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3: 
> >> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ 
> was 
> >> > here 
> >> >  extern FILE *fopen (const char *__restrict __filename, 
> >> >   ^ 
> >> > 
> >> > /tmp/go-build775342366/
> github.com/walkert/loader/_obj/_cgo_export.c:17:7: 
> >> > error: conflicting types for ‘fopen’ 
> >> >  FILE* fopen(char* p0, char* p1) 
> >> >^ 
> >> > In file included from ./main.go:5:0, 
> >> >  from 
> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3: 
> >> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ 
> was 
> >> > here 
> >> >  extern FILE *fopen (const char *__restrict __filename, 
> >> >   ^ 
> >> > 
> >> > I've seen this before when I was trying to return an int instead of 
> >> > C.int so 
> >> > I have a feeling I'm missing something simple here. Any pointers 
> would 
> >> > be 
> >> > much appreciated. 
> >> 
> >> It looks like the same file is doing #include  and `//export 
> >> fopen`.  That won't work, because, as you can see, the definition of 
> >> the Go function fopen will conflict with the declaration in stdio.h. 
> >> 
> >> 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...@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: Passing a string

[Chun Zhang]

Hi,  Ian, 

Sorry about the confusion!  My gocode set the value of the device and then 
pass it to C++ code. 

Code goes like this:

device := "eth1" // hardcoding this value works or retrieving it from Flag 
as below

flag.StringVar(&device, "Device", "eth1", "NIC to Listen")


--- lines below do not change 

itc := device // with or without this.
libpi.PI_init_global_config(1, &itc)

func PI_init_global_config(arg1 int, arg2 *string) {
_swig_i_0 := arg1
_swig_i_1 := arg2

C._wrap_PI_init_global_config_libpi_de8cf075b4f6dbec(C.swig_intgo(_swig_i_0), 
C.swig_voidp(_swig_i_1))
}


void _wrap_PI_init_global_config_libpi_de8cf075b4f6dbec(intgo _swig_go_0, 
_gostring_* _swig_go_1) {
  int arg1 ;
  char **arg2 ;

  arg1 = (int)_swig_go_0;
  arg2 = *(char ***)&_swig_go_1;

  PI_init_global_config(arg1,arg2);

}

Then eventually to the C++ library with function header defined as

void PI_init_global_config(int argc, char *argv[]);

---

If I am trying to retrieve the value of var device from a json file, such 
as 

 file, err := os.Open("config.json")
if err != nil {
return
}
defer file.Close()

decoder1 := json.NewDecoder(file)
conf := &Configuration{}
err = decoder1.Decode(conf)
fmt.Println("conf is ", conf) // the print shows that I get eth1
if err != nil {
return
}

device = conf.device //fmt.println gives eth1
or

device = fmt.Sprintf("%s", conf.Device)

The code always crashes with the go pointer error. 

I just don't understand what is the difference between hardcoding the value 
and retrieving it from the json file. Can you please help me to understand 
it?

Thanks,
Chun

On Monday, November 6, 2017 at 1:44:54 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Nov 6, 2017 at 10:29 AM, Chun Zhang  > wrote: 
> > Thank you Ian!! That does make sense. 
> > 
> > Can you please elaborate why hardcoding device = "eth1" works? What is 
> the 
> > difference here? 
>
> I'm sorry, I'm not sure I really understand the question.  The pointer 
> passing rules apply only when calling functions written in C rather 
> than Go.  When you write `device = "eth1"` there is no C function 
> involved. 
>
> Ian 
>
> > On Mon, Nov 6, 2017 at 1:19 PM, Ian Lance Taylor  > wrote: 
> >> 
> >> On Mon, Nov 6, 2017 at 4:25 AM, Chun Zhang  > wrote: 
> >> > 
> >> > Thank you for the reply! 
> >> > 
> >> > The C libi.PI_init_global_config has the interface of 
> >> > PI_init_global_config(int argc, char *argv[]); 
> >> > so Swig converts it to PI_init_global_config(arg1 int, arg2 *string) 
> >> > 
> >> > The code was expecting to a *string. Viper.GetString returns a string 
> as 
> >> > far 
> >> > as I can see, is that right? So device is a string, not a *string. 
> >> > (verified 
> >> > with reflect.TypeOf). Everything matches except for the crash :( 
> >> > 
> >> > What really puzzles me is that why when passing the parameter using 
> flag 
> >> > is 
> >> > fine, as well as when hard-coding the value. In both cases, device is 
> >> > still 
> >> > a string, nothing changed. But whenever trying to read the value from 
> a 
> >> > config file using viper or just simple json.decoder, the code 
> complains 
> >> > it 
> >> > is a pointer to a pointer. I mean, I literally did a comparison 
> between 
> >> > the 
> >> > read-in value and a variable hard-coded as "eth1", it says they are 
> >> > equal. 
> >> 
> >> A Go string contains an internal pointer.  Passing a *string to cgo 
> >> means that you are passing a pointer to a string that contains a 
> >> pointer, so you are passing a pointer to a pointer.  That is invalid 
> >> according to the cgo pointer passing rules. 
> >> 
> >> A Go string is definitely not a C or C++ string.  You can not pass a 
> >> pointer to a Go string to C code that expects a char**.  Even if cgo 
> >> permitted it, it would not work.  If SWIG is converting a C char** (or 
> >> char*[]) to Go *string, then SWIG is getting it wrong. 
> >> 
> >> Ian 
> >> 
> >> 
> >> > On Monday, November 6, 2017 at 1:07:46 AM UTC-5, Tamás Gulácsi wrote: 
> >> >> 
> >> >> 
> >> >> 2017. november 6., hétfő 2:11:48 UTC+1 időpontban Chun Zhang a 
> >> >> következőt 
> >> >> írta: 
> >> >>> 
> >> >>> Hi, All, 
> >> >>> 
> >> >>> I am trying to read a configuration file using Viper, the config 
> file 
> >> >>> is 
> >> >>> a very simple json file with one line 
> >> >>> { 
> >> >>> "device" : "eth1" 
> >> >>> } 
> >> >>> 
> >> >>> I use the following line to read it 
> >> >>> 
> >> >>> device := viper.GetString("device") 
> >> >>> 
> >> >>> 
> >> >>> then passing this var further into a C library with swig generated 
> api 
> >> >>> as 
> >> >>> arg2 
> >> >>> 
> >> >>> itc := device //Need to update if there is more devices 
> >> >>> libpi.PI_init_global_config(1, &itc) 
> >> >>> 
> >> >>> func PI_init_global_config(arg1 int,

Re: [go-nuts] Re: Passing a string

[Tamás Gulácsi]

Please, can you share the complete code?
What is "Configuration"?
What does `fmt.Sprintf("%T %#v", conf, conf)` print?

I'm not sure about the swig-generated code, is your swig new enough?

-- 
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] Unescape html in template/html

[Chad Caglak]

Hi All,
 
I am building a twitter clone to learn golang and i need to unescape the 
hashtag url.

full source in github github.com/ccaglak/twr 

thanks all in advance

for i, v := range gPost {
h := GetHashTags(v.Post)
for _, ht := range h {

gPost[i].Post = strings.Replace(gPost[i].Post, ht, ""+ht+"", -1)

}
}

if a == true {
tmpl.ExecuteTemplate(w, "timeline.htm", &App{Post: gPost, FUser: 
foll})
} else {
http.Redirect(w, r, "/login", 302)
}

-- 
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] goto from inner select

[Michael Jones]

this is what you are not seeing... https://play.golang.org/p/tx9vAOnOoL

On Mon, Nov 6, 2017 at 10:22 AM,  wrote:

>
>
> On Monday, November 6, 2017 at 8:03:28 PM UTC+2, Ian Lance Taylor wrote:
>>
>> On Mon, Nov 6, 2017 at 8:55 AM,   wrote:
>> >
>> > Can someone explain, is this program  is really incorrect:
>> > https://play.golang.org/p/0fp9Nt_99L
>> >
>> > trying to run it results in error:
>> > tmp/sandbox536393528/main.go:16:9: goto C jumps into block starting at
>> > tmp/sandbox536393528/main.go:10:2
>> > but goto jumps in outside block.
>>
>> Every case in a switch is an implicit block, so, yes, this program is
>> invalid and the compiler is telling you why.
>>
>
> Thanks for clear explanation
>
>
>>
>> > I trying to make priority select by nesting selects, and want to find
>> way to
>> > write logic only in one place.
>>
>> Use a function?
>
>
> Yes, i consider using functions, just wonder why goto does not work,
>
> Thanks again.
>
> Jamil Djadala
>
>
>
>
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
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 to determine the correct method signature to override fopen

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 10:58 AM,   wrote:
>
> In that case - do you know how I can inspect the comparison it's doing?
> Since I'm already doing this for the open system call, I know that it's
> possible to write a function with the same definition. It seems in this case
> that I'm not matching the representation that cgo is expecting. I would
> therefore like to see what cgo thing it looks like so I can attempt to get a
> perfect match. Would that be possible?

Perhaps it is possible but I don't see a way.  I think it works for
open coincidentally; there just happens to be no conflict between the
declaration in the header file and the definition that cgo generates.

Ian


> On Friday, November 3, 2017 at 11:50:36 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Fri, Nov 3, 2017 at 5:44 PM,   wrote:
>> >
>> > Thanks Ian. I had included that because it seems required in order for
>> > me to
>> > refer to the return type (C.FILE) and so I can access the underlying
>> > C.fopen
>> > function.  This is the approach I have with open but perhaps this is
>> > different.
>> > If I'm not supposed to use the include, can you advise how I should
>> > refer to
>> > the type/function from the header?
>>
>> I'm sorry, nothing comes to mind.  In C you would just write the
>> declaration the way the header file expects, but cgo doesn't provide a
>> way to do that.
>>
>> Ian
>>
>>
>> > On Friday, November 3, 2017 at 8:28:38 PM UTC-4, Ian Lance Taylor wrote:
>> >>
>> >> On Fri, Nov 3, 2017 at 2:24 PM,   wrote:
>> >> >
>> >> > I've been writing a shared-object which I'll use via LD_PRELOAD to
>> >> > override
>> >> > the open syscall. This is currently working OK but now I want to move
>> >> > on
>> >> > to
>> >> > fopen. I've defined it (as far as I can tell) in-line with the stdio
>> >> > header
>> >> > see here. However, when I try and build:
>> >> >
>> >> > $ go build -buildmode=c-shared
>> >> > # github.com/walkert/loader
>> >> > In file included from
>> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0:
>> >> > ./main.go:56:14: error: conflicting types for ‘fopen’
>> >> > In file included from ./main.go:5:0,
>> >> >  from
>> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
>> >> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’
>> >> > was
>> >> > here
>> >> >  extern FILE *fopen (const char *__restrict __filename,
>> >> >   ^
>> >> >
>> >> >
>> >> > /tmp/go-build775342366/github.com/walkert/loader/_obj/_cgo_export.c:17:7:
>> >> > error: conflicting types for ‘fopen’
>> >> >  FILE* fopen(char* p0, char* p1)
>> >> >^
>> >> > In file included from ./main.go:5:0,
>> >> >  from
>> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
>> >> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’
>> >> > was
>> >> > here
>> >> >  extern FILE *fopen (const char *__restrict __filename,
>> >> >   ^
>> >> >
>> >> > I've seen this before when I was trying to return an int instead of
>> >> > C.int so
>> >> > I have a feeling I'm missing something simple here. Any pointers
>> >> > would
>> >> > be
>> >> > much appreciated.
>> >>
>> >> It looks like the same file is doing #include  and `//export
>> >> fopen`.  That won't work, because, as you can see, the definition of
>> >> the Go function fopen will conflict with the declaration in stdio.h.
>> >>
>> >> 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...@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] Re: Passing a string

[Chun Zhang]

Hi, 

The configuration is the structure defined as 

type Configuration struct {
IpToSend string
PortToSend   string
Device   string
}

The json file is 
{
  "IpToSend" :"",
  "PortToSend" :"2075",
  "Device" : "eth1"
}

The output of fmt.Sprintf("%T %#v", conf, conf) is

&main.Configuration{IpToSend:"", PortToSend:"2075", Device:"eth1"}

Swig if of version 3.0, I recently generated these code.

Thank you so much!


Chun

On Monday, November 6, 2017 at 2:27:58 PM UTC-5, Tamás Gulácsi wrote:
>
> Please, can you share the complete code?
> What is "Configuration"?
> What does `fmt.Sprintf("%T %#v", conf, conf)` print?
>
> I'm not sure about the swig-generated code, is your swig new enough?
>

-- 
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: Passing a string

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 10:59 AM, Chun Zhang  wrote:
>
> Sorry about the confusion!  My gocode set the value of the device and then
> pass it to C++ code.
>
> Code goes like this:
>
> device := "eth1" // hardcoding this value works or retrieving it from Flag
> as below
>
> flag.StringVar(&device, "Device", "eth1", "NIC to Listen")

It would help if you showed a complete standalone example, but I think
I see what you mean.  This works because the current compiler produces
a string literal for "eth1" that is stored in the program itself.  The
internal string pointer points into the program text segment, and so
it is not a Go pointer, and so you do not get the error.

A Go *string is still not a C char**, but I guess that a *string does
look like C struct { char *p; uintptr_t n; }*, so since you are
passing only a single string it may be working by accident.  Note that
the Go string is not necessarily NUL-terminated, but perhaps in this
case it happens to be.

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] Re: Passing a string

[Chun Zhang]

Thanks Ian!

Can you please give some suggestion on how to properly handle this issue? 
The C++ API cannot be modified. 

Sincerely, 
Chun

On Monday, November 6, 2017 at 3:25:13 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Nov 6, 2017 at 10:59 AM, Chun Zhang  > wrote: 
> > 
> > Sorry about the confusion!  My gocode set the value of the device and 
> then 
> > pass it to C++ code. 
> > 
> > Code goes like this: 
> > 
> > device := "eth1" // hardcoding this value works or retrieving it from 
> Flag 
> > as below 
> > 
> > flag.StringVar(&device, "Device", "eth1", "NIC to Listen") 
>
> It would help if you showed a complete standalone example, but I think 
> I see what you mean.  This works because the current compiler produces 
> a string literal for "eth1" that is stored in the program itself.  The 
> internal string pointer points into the program text segment, and so 
> it is not a Go pointer, and so you do not get the error. 
>
> A Go *string is still not a C char**, but I guess that a *string does 
> look like C struct { char *p; uintptr_t n; }*, so since you are 
> passing only a single string it may be working by accident.  Note that 
> the Go string is not necessarily NUL-terminated, but perhaps in this 
> case it happens to be. 
>
> 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] Re: Passing a string

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 2:17 PM, Chun Zhang  wrote:
>
> Can you please give some suggestion on how to properly handle this issue?
> The C++ API cannot be modified.

Use C.CString as described in the cgo docs at https://golang.org/cmd/cgo .

Ian



> On Monday, November 6, 2017 at 3:25:13 PM UTC-5, Ian Lance Taylor wrote:
>>
>> On Mon, Nov 6, 2017 at 10:59 AM, Chun Zhang  wrote:
>> >
>> > Sorry about the confusion!  My gocode set the value of the device and
>> > then
>> > pass it to C++ code.
>> >
>> > Code goes like this:
>> >
>> > device := "eth1" // hardcoding this value works or retrieving it from
>> > Flag
>> > as below
>> >
>> > flag.StringVar(&device, "Device", "eth1", "NIC to Listen")
>>
>> It would help if you showed a complete standalone example, but I think
>> I see what you mean.  This works because the current compiler produces
>> a string literal for "eth1" that is stored in the program itself.  The
>> internal string pointer points into the program text segment, and so
>> it is not a Go pointer, and so you do not get the error.
>>
>> A Go *string is still not a C char**, but I guess that a *string does
>> look like C struct { char *p; uintptr_t n; }*, so since you are
>> passing only a single string it may be working by accident.  Note that
>> the Go string is not necessarily NUL-terminated, but perhaps in this
>> case it happens to be.
>>
>> 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.

-- 
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] type returned by reflect.ArrayOf breaks the spec

[Josh Humphries]

I think I've found a bug regarding reflect.ArrayOf. The go doc is a bit
light, but suggests that the resulting type is a proper array type.
However, I've found that the resulting type has a few flaws:


   1. The resulting array type violates part of the language spec about
   arrays: it cannot be used as a map key. Using an array whose type was
   created via reflect.ArrayOf as a key in a map results in a runtime panic:


*runtime error: hash of unhashable type [8]int32 *
   See the link below for an example program that shows this error.

   2. The resulting array type seems to violate the reflect package Go doc
   regarding reflect.Type and type equality. The package doc states this:


*Type values are comparable, such as with the == operator. Two Type
   values are equal if they represent identical types. *
   And the section about type identity in the language spec states this:

   *Two array types are identical if they have identical element types
   and the same array length.*

   However, an array type created using reflect.ArrayOf returns false when
   compared to an identical type that was *not* created using
   reflect.ArrayOf.

   The link below also shows an example of this erroneous behavior.

Demonstrations of these issues:
https://play.golang.org/p/Qu0irn2rCF

I am guessing I should just file a bug in a Github issue, but wanted to
first check to see if this, somehow, might be expected behavior. (And if
so, to learn why.)


*Josh Humphries*
jh...@bluegosling.com

-- 
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] type returned by reflect.ArrayOf breaks the spec

[Ian Lance Taylor]

On Mon, Nov 6, 2017 at 2:50 PM, Josh Humphries  wrote:
>
> I think I've found a bug regarding reflect.ArrayOf. The go doc is a bit
> light, but suggests that the resulting type is a proper array type. However,
> I've found that the resulting type has a few flaws:
>
> The resulting array type violates part of the language spec about arrays: it
> cannot be used as a map key. Using an array whose type was created via
> reflect.ArrayOf as a key in a map results in a runtime panic:
>
>  runtime error: hash of unhashable type [8]int32
>
> See the link below for an example program that shows this error.
>
> The resulting array type seems to violate the reflect package Go doc
> regarding reflect.Type and type equality. The package doc states this:
>
> Type values are comparable, such as with the == operator. Two Type
> values are equal if they represent identical types.
>
> And the section about type identity in the language spec states this:
>
> Two array types are identical if they have identical element types and
> the same array length.
>
> However, an array type created using reflect.ArrayOf returns false when
> compared to an identical type that was not created using reflect.ArrayOf.
>
> The link below also shows an example of this erroneous behavior.
>
> Demonstrations of these issues:
> https://play.golang.org/p/Qu0irn2rCF
>
> I am guessing I should just file a bug in a Github issue, but wanted to
> first check to see if this, somehow, might be expected behavior. (And if so,
> to learn why.)

This is not expected behavior.  Oddly, I can not recreate the problem.
I mean, I see that it happens on the playground, but it seems to work
correctly when I run the program on my laptop.  Ah, but it fails, at
least on tip, if I use `GOARCH=386`.  Please do open an issue.
Thanks.

Ian

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

[go-nuts] [Request] Official golang debugger

[Florin Pățan]

Delve is the one towards which the community rally since gdb, still, doesn't 
play nice with goroutines. So, for all intents and purposes, delve is the 
official debugger and the Go Team and Delve Team do work together to give us a 
better debugging experience. But sometimes the problems that need to be fixed 
are just too hard to do so quickly. 

-- 
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] A way to detect closed channel

[Albert Tedja]

So, I just found out that closed channels always yield the zero value. That 
means, a closed channel inside a select statement seems to always be 
guaranteed to be executed.

Since closing an already closed channel creates a panic, does this mean 
then I can do this to make sure that the channel is closed only once?


select {
case <- closedchan:
default:
close(closedchan)
}



Golang playground: https://play.golang.org/p/LSrTh0HC2K

It seems to work. Just want to confirm here before start doing this 
everywhere in my 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] Re: A way to detect closed channel

[Albert Tedja]

Assuming of course, that the channel is only intended to send closed signal 
to other goroutines, rather than transporting meaningful data.

On Monday, November 6, 2017 at 4:59:51 PM UTC-8, Albert Tedja wrote:
>
> So, I just found out that closed channels always yield the zero value. 
> That means, a closed channel inside a select statement seems to always be 
> guaranteed to be executed.
>
> Since closing an already closed channel creates a panic, does this mean 
> then I can do this to make sure that the channel is closed only once?
>
>
> select {
> case <- closedchan:
> default:
> close(closedchan)
> }
>
>
>
> Golang playground: https://play.golang.org/p/LSrTh0HC2K
>
> It seems to work. Just want to confirm here before start doing this 
> everywhere in my 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.

Re: [go-nuts] A way to detect closed channel

[Dan Kortschak]

No. The complete select+code blocks is not atomic, so the select may
see that closedchan is not closed, execute the default case, but in the
mean time closedchan has been closed by someone else. Bang!

On Mon, 2017-11-06 at 16:59 -0800, Albert Tedja wrote:
> Since closing an already closed channel creates a panic, does this
> mean 
> then I can do this to make sure that the channel is closed only once?
> 
> 
> select {
>     case <- closedchan:
>     default:
>     close(closedchan)
> }



-- 
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] A way to detect closed channel

[Daniel Skinner]

meaning, don't call that select+code block from multiple goroutines. If on
the other-hand that block is always called from the same goroutine, then it
will do what you want, but that may be a slippery slope depending on what
you're writing.

On Mon, Nov 6, 2017 at 7:33 PM Dan Kortschak 
wrote:

> No. The complete select+code blocks is not atomic, so the select may
> see that closedchan is not closed, execute the default case, but in the
> mean time closedchan has been closed by someone else. Bang!
>
> On Mon, 2017-11-06 at 16:59 -0800, Albert Tedja wrote:
> > Since closing an already closed channel creates a panic, does this
> > mean
> > then I can do this to make sure that the channel is closed only once?
> >
> >
> > select {
> > case <- closedchan:
> > default:
> > close(closedchan)
> > }
>
>
>
> --
> 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] A way to detect closed channel

[Albert Tedja]

That makes sense.  If multiple goroutines are calling that select block, 
one or more could be attempting to close it.

Okay, nevermind then.

-- 
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: A way to detect closed channel

[sheepbao]

func isClose() bool {
select {
case <-closeChan:
return true
default:
return false
}
}




在 2017年11月7日星期二 UTC+8上午8:59:51，Albert Tedja写道：
>
> So, I just found out that closed channels always yield the zero value. 
> That means, a closed channel inside a select statement seems to always be 
> guaranteed to be executed.
>
> Since closing an already closed channel creates a panic, does this mean 
> then I can do this to make sure that the channel is closed only once?
>
>
> select {
> case <- closedchan:
> default:
> close(closedchan)
> }
>
>
>
> Golang playground: https://play.golang.org/p/LSrTh0HC2K
>
> It seems to work. Just want to confirm here before start doing this 
> everywhere in my 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.

Re: [go-nuts] Re: A way to detect closed channel

[Dan Kortschak]

This is not a good idea (and is wrong since it does not check the ok
value of the receive operation). As was pointed out previously, this is
only true in the instant that the select is occurring.

On Mon, 2017-11-06 at 18:39 -0800, sheepbao wrote:
> func isClose() bool {
>     select {
>     case <-closeChan:
>     return true
>     default:
>     return false
>     }
> }



-- 
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: A way to detect closed channel

[Dave Cheney]

This is not safe. https://play.golang.org/p/ax6fG_ZCE_ 

On Tuesday, 7 November 2017 11:59:51 UTC+11, Albert Tedja wrote:
>
> So, I just found out that closed channels always yield the zero value. 
> That means, a closed channel inside a select statement seems to always be 
> guaranteed to be executed.
>
> Since closing an already closed channel creates a panic, does this mean 
> then I can do this to make sure that the channel is closed only once?
>
>
> select {
> case <- closedchan:
> default:
> close(closedchan)
> }
>
>
>
> Golang playground: https://play.golang.org/p/LSrTh0HC2K
>
> It seems to work. Just want to confirm here before start doing this 
> everywhere in my 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] Re: [Request] Official golang debugger

[Sotirios Mantziaris]

Yes i know that, but i wonder if it is time to fully integrate delve in the 
go toolchain and ship it with every release like dep, which exists in 
another repository, but will be fullly integrated into the toolchain and 
the releases in some future version.

On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>
> Delve is the one towards which the community rally since gdb, still, 
> doesn't play nice with goroutines. So, for all intents and purposes, delve 
> is the official debugger and the Go Team and Delve Team do work together to 
> give us a better debugging experience. But sometimes the problems that need 
> to be fixed are just too hard to do so quickly. 

-- 
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: [Request] Official golang debugger

[Florin Pățan]

I hope not. Anything that ends up in the toolchain is slow to change and
adapt to user needs. If I have a problem with delve today, I can post an
issue, fix it and get the next version of delve az quick as a few hours. If
it would be in the toolchain it could take up to six months to get it
released.

On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, 
wrote:

> Yes i know that, but i wonder if it is time to fully integrate delve in
> the go toolchain and ship it with every release like dep, which exists in
> another repository, but will be fullly integrated into the toolchain and
> the releases in some future version.
>
> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>>
>> Delve is the one towards which the community rally since gdb, still,
>> doesn't play nice with goroutines. So, for all intents and purposes, delve
>> is the official debugger and the Go Team and Delve Team do work together to
>> give us a better debugging experience. But sometimes the problems that need
>> to be fixed are just too hard to do so quickly.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] network programming about go

[Karan Chaudhary]

Is the port 5000 on 192.168.153.239 open?  If it is open,  is your server 
running on that port?

https://stackoverflow.com/questions/2972600/no-connection-could-be-made-because-the-target-machine-actively-refused-it

On Monday, 6 November 2017 19:30:22 UTC+5:30, 28911...@gmail.com wrote:
>
> I try to modify the program,but the result is: host:portfatal error: dial 
> tcp 192.168.153.239:5000: connectex: No connection could be made because 
> the target machine actively refused it.exit status 1.How to solve it??
>
> 在 2017年11月6日星期一 UTC+8下午5:08:26，rog写道：
>
>> On 30 October 2017 at 06:55,  <28911...@gmail.com> wrote: 
>> > I write this code in the follwings: 
>> > package main 
>> > 
>> > import ( 
>> > "fmt" 
>> > "net" 
>> > "os" 
>> > ) 
>> > 
>> > func main() { 
>> > service := ":5000" 
>> > tcpAddr, err := net.ResolveTCPAddr("tcp", service) 
>> > checkError(err) 
>> > listener, err := net.ListenTCP("tcp", tcpAddr) 
>> > 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])) 
>> > _, err2 := conn.Write([]byte("welcome client!")) 
>> > if err2 != nil { 
>> > return 
>> > } 
>> > } 
>> > } 
>> > func checkError(err error) { 
>> > if err != nil { 
>> > fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error()) 
>> > os.Exit(1) 
>> > } 
>> > } 
>> > 
>> > 
>> > I try to run it in Sublime Text3 but it has no reaction and I try to 
>> run it 
>> > in running windows, it shows: 
>> > fatal error: lsiten tcp:5000:bind:Only one usage of each socket 
>> > address(protocol/network address/port) is normally permitted.exit 
>> status 1 
>>
>> From that error message, I suspect that you already have a running 
>> instance 
>> of your program - as the message says, you are only allowed to listen 
>> on a port once. 
>>
>> To avoid that, you could listen on port zero, which will choose an 
>> arbitrary 
>> port (but then you'll need to print out the port number so that you can 
>> know which port to use on the client). 
>>
>> By the way, your code is a little bit more complex than 
>> it needs to be. Instead of this: 
>>
>> > service := ":5000" 
>> > tcpAddr, err := net.ResolveTCPAddr("tcp", service) 
>> > checkError(err) 
>> > listener, err := net.ListenTCP("tcp", tcpAddr) 
>>
>> You could do: 
>>
>> service := ":5000" 
>> listener, err := net.Listen("tcp", tcpAddr) 
>>
>> Similarly when dialing - there's no need to call ResolveTCPAddr 
>> explicitly (and it's actually not as good if you do that, 
>> because Dial will automatically use multiple IP addresses 
>> if it needs to, but if you use ResolveTCPAddr, it can only use one). 
>>
>> Hope this helps, 
>>
>>   rog. 
>>
>

-- 
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: [Request] Official golang debugger

[Sotirios Mantziaris]

I do not know if the times you mentioned are indeed that long.
If it is true then you actually have a good argument.

On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>
> I hope not. Anything that ends up in the toolchain is slow to change and 
> adapt to user needs. If I have a problem with delve today, I can post an 
> issue, fix it and get the next version of delve az quick as a few hours. If 
> it would be in the toolchain it could take up to six months to get it 
> released. 
>
> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris,  > wrote:
>
>> Yes i know that, but i wonder if it is time to fully integrate delve in 
>> the go toolchain and ship it with every release like dep, which exists in 
>> another repository, but will be fullly integrated into the toolchain and 
>> the releases in some future version.
>>
>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>>>
>>> Delve is the one towards which the community rally since gdb, still, 
>>> doesn't play nice with goroutines. So, for all intents and purposes, delve 
>>> is the official debugger and the Go Team and Delve Team do work together to 
>>> give us a better debugging experience. But sometimes the problems that need 
>>> to be fixed are just too hard to do so quickly. 
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: [Request] Official golang debugger

[Dave Cheney]

If you reported an issue today, Nov 6, you could be waiting nearly 9 months 
to see a fix in the next released version of Go.

A project living outside the standard library has little going against it 
other than you have to compile it yourself.

On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote:
>
> I do not know if the times you mentioned are indeed that long.
> If it is true then you actually have a good argument.
>
> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>>
>> I hope not. Anything that ends up in the toolchain is slow to change and 
>> adapt to user needs. If I have a problem with delve today, I can post an 
>> issue, fix it and get the next version of delve az quick as a few hours. If 
>> it would be in the toolchain it could take up to six months to get it 
>> released. 
>>
>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris,  
>> wrote:
>>
>>> Yes i know that, but i wonder if it is time to fully integrate delve in 
>>> the go toolchain and ship it with every release like dep, which exists in 
>>> another repository, but will be fullly integrated into the toolchain and 
>>> the releases in some future version.
>>>
>>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:

 Delve is the one towards which the community rally since gdb, still, 
 doesn't play nice with goroutines. So, for all intents and purposes, delve 
 is the official debugger and the Go Team and Delve Team do work together 
 to 
 give us a better debugging experience. But sometimes the problems that 
 need 
 to be fixed are just too hard to do so quickly. 
>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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.