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

[Jan Mercl]

On Sun, Nov 5, 2017 at 3:16 AM Ben Hoyt  wrote:

> Hence the confusion. Sure, append can write to the underlying array
because that's effectively passed by reference. But it can't update the
length of the slice itself, unless you return it.

I don't follow. It had been shown, that the result of append is actually
not needed/can be constructed by other means - except in the case where the
backing array gets reallocated. Then you can't get away without it.

BTW, I recommend to not think in terms of references. The Go language
specification does not mention nor define that term and there's not just a
single meaning of "reference". Also, references are commonly regarded not
the same thing as pointers.

-- 

-j

-- 
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: goroutines with better exceptions

[Keith Brown]

sure, in line 16.

So, don't continue means I can do this?

ch <- Result{500}
return




On Saturday, November 4, 2017 at 5:26:37 PM UTC-4, Tamás Gulácsi wrote:
>
> If err!=nil, response is nil, too - so don't continue!

-- 
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: goroutines with better exceptions

[Tamás Gulácsi]

yes

-- 
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()

[Ben Hoyt]

>
> I don't follow. It had been shown, that the result of append is actually
> not needed/can be constructed by other means - except in the case where the
> backing array gets reallocated. Then you can't get away without it.
>

Hmmm, it feels like we're talking past each other. Of course you can ignore
the result if you're going to re-implement parts of what append() does
yourself. Just like you can ignore the result of GenFibonacciNumber() if
you calculate the value yourself afterwards. I see what you mean, but that
feels like "cheating".

Anyway, let's leave that and change tack -- the gist of my confusion is
shown by these two different statements from Effective Go:

1) "We must return the slice afterwards because ... the slice itself (the
run-time data structure holding the pointer, length, and capacity) is
passed by value."

2) "The result needs to be returned because, as with our hand-written
Append, the underlying array may change."

Two different reasons are given for why append() needs to return a value:
because the slice is passed by value, or because the underlying array may
change. Which is it? This is why I'm confused. And it seems to me that #1
is the actual (or at least the clearer) reason.

-Ben

-- 
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()

[Tamás Gulácsi]

Both reasons correct: the underlying array, length and cap may change, and as 
all arguments are pasded by value, we can't see the change if we don't use 
(assign) the returned value.

-- 
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] Expected ambigiuous reference error, got a value instead

[Daniel Skinner]

The spec uses "shallowest depth", not "shortest path", as I assume saying
"path" would imply the given names in a selector expression determine
ambiguity when they do not.

"shallowest depth" makes the error more clear in my sample where if this:

type Uniform GLUniform

is changed to this:

type Uniform struct {
GLUniform
}

access to the Value fields would now exist at the same depth and produce
the error I was expecting to see.

https://golang.org/ref/spec#Selectors

On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:

> Right, I've misunderstood why this error is thrown, as in what defines
> ambiguity. Text search of spec for "ambig" only yields results for
> composite literals and avoiding ambiguity in conversions while "shortest"
> yields no results and the only recollection of "shortest path wins" phrase
> I have is back when vendor directory was introduced.
>
> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>>
>> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:
>>
>> > https://play.golang.org/p/Y1UxMgNhWx
>> >
>> > I ran into this today but don't understand why the compiler isn't
>> throwing an ambiguous reference error. Maybe I've misunderstood why this
>> error is thrown the few times I've seen it.
>>
>> No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
>> and the other one is sample.Uniform.Value and the specs say the shortest
>> path wins.
>>
>> --
>>
>> -j
>>
>

-- 
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] Expected ambigiuous reference error, got a value instead

[Jan Mercl]

I don't know when the shallowest depth can occur while not being on
shortest path.  Note that path was used in this discussion as meaning full,
unpromoted path, ie. like if every embedded field of type T was declared T
T instead. The actual selector expression is a prefix of this full path.

On Sun, Nov 5, 2017, 16:59 Daniel Skinner  wrote:

> The spec uses "shallowest depth", not "shortest path", as I assume saying
> "path" would imply the given names in a selector expression determine
> ambiguity when they do not.
>
> "shallowest depth" makes the error more clear in my sample where if this:
>
> type Uniform GLUniform
>
> is changed to this:
>
> type Uniform struct {
> GLUniform
> }
>
> access to the Value fields would now exist at the same depth and produce
> the error I was expecting to see.
>
> https://golang.org/ref/spec#Selectors
>
> On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:
>
>> Right, I've misunderstood why this error is thrown, as in what defines
>> ambiguity. Text search of spec for "ambig" only yields results for
>> composite literals and avoiding ambiguity in conversions while "shortest"
>> yields no results and the only recollection of "shortest path wins" phrase
>> I have is back when vendor directory was introduced.
>>
>> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>>
>>>
>>> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:
>>>
>>> > https://play.golang.org/p/Y1UxMgNhWx
>>> >
>>> > I ran into this today but don't understand why the compiler isn't
>>> throwing an ambiguous reference error. Maybe I've misunderstood why this
>>> error is thrown the few times I've seen it.
>>>
>>> No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
>>> and the other one is sample.Uniform.Value and the specs say the shortest
>>> path wins.
>>>
>>> --
>>>
>>> -j
>>>
>> --

-j

-- 
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 does go compiler link executable to glibc without an apparent reason?

[Howard Guo]

Hello fellow gophers.

I've a small number of go programs that only use standard library functions 
without any 3rd party library dependency. A strange behaviour was observed 
during compilation (go build) - most of them compile into static 
executable, but few of them end up linking to glibc. Without an exception, 
all of them compile into static executable when CGO_ENABLED=0 is set prior 
to compilation, and their runtime behaviour doesn't change at all.

What could be the obscure reasons for go compiler to link executable to 
glibc?

Thanks.

Kind regards,
Howard

-- 
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] Is something like SIMD "math/vector" planned?

[David M.]

Hi,

I'm interested in high performance applications in Go, and I saw the new 
"math/bits" package. I think it's very nice that the compiler replaces the 
Go implementation with special CPU instructions when the architecture 
supports it.

My question is, is there a plan to do something similar with basic 
arithmetic on small floating point vector types (things like [4]float32) 
implementing them with SSE/AVX/...?

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.

Re: [go-nuts] who does go compiler link executable to glibc without an apparent reason?

[Jan Mercl]

Using some of the net/... package calls libc unless disabled.

On Sun, Nov 5, 2017, 17:13 Howard Guo  wrote:

> Hello fellow gophers.
>
> I've a small number of go programs that only use standard library
> functions without any 3rd party library dependency. A strange behaviour was
> observed during compilation (go build) - most of them compile into static
> executable, but few of them end up linking to glibc. Without an exception,
> all of them compile into static executable when CGO_ENABLED=0 is set prior
> to compilation, and their runtime behaviour doesn't change at all.
>
> What could be the obscure reasons for go compiler to link executable to
> glibc?
>
> Thanks.
>
> Kind regards,
> Howard
>
> --
> 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.
>
-- 

-j

-- 
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] Expected ambigiuous reference error, got a value instead

[Daniel Skinner]

> I don't know when the shallowest depth can occur while not being on
shortest path

I know the feeling if we're generally talking about data structures and
algorithms, but with regards to language spec, the only mental reference I
have for "path" is for "import paths" of which the actual name is
important. Searching the spec for "path" in fact only turns up references
to import path.

So on sight, I assumed "shortest path" meant changing `Texture` to `Tex`
would affect resolution, which I also knew to be incorrect. It's my own
failing but thanks for pointing me in the right direction as I was at a
loss for where to even start as the visual cue of `type  A B` vs `type A
struct {B}` didn't register wrt the desired error for me.

On Sun, Nov 5, 2017 at 10:09 AM Jan Mercl <0xj...@gmail.com> wrote:

> I don't know when the shallowest depth can occur while not being on
> shortest path.  Note that path was used in this discussion as meaning full,
> unpromoted path, ie. like if every embedded field of type T was declared T
> T instead. The actual selector expression is a prefix of this full path.
>
> On Sun, Nov 5, 2017, 16:59 Daniel Skinner  wrote:
>
>> The spec uses "shallowest depth", not "shortest path", as I assume saying
>> "path" would imply the given names in a selector expression determine
>> ambiguity when they do not.
>>
>> "shallowest depth" makes the error more clear in my sample where if this:
>>
>> type Uniform GLUniform
>>
>> is changed to this:
>>
>> type Uniform struct {
>> GLUniform
>> }
>>
>> access to the Value fields would now exist at the same depth and produce
>> the error I was expecting to see.
>>
>> https://golang.org/ref/spec#Selectors
>>
>> On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:
>>
>>> Right, I've misunderstood why this error is thrown, as in what defines
>>> ambiguity. Text search of spec for "ambig" only yields results for
>>> composite literals and avoiding ambiguity in conversions while "shortest"
>>> yields no results and the only recollection of "shortest path wins" phrase
>>> I have is back when vendor directory was introduced.
>>>
>>> On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>

 On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:

 > https://play.golang.org/p/Y1UxMgNhWx
 >
 > I ran into this today but don't understand why the compiler isn't
 throwing an ambiguous reference error. Maybe I've misunderstood why this
 error is thrown the few times I've seen it.

 No ambiguity here. One of the Value(s) is
 sample.Texture.GLTexture.Value and the other one is sample.Uniform.Value
 and the specs say the shortest path wins.

 --

 -j

>>> --
>
> -j
>

-- 
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] Expected ambigiuous reference error, got a value instead

[Jan Mercl]

I consider foo.bar and f.b to be of the same length, as in length of a
list, 2 in this case, not length of a string. But I failed to be clear
about it.

On Sun, Nov 5, 2017, 17:38 Daniel Skinner  wrote:

> > I don't know when the shallowest depth can occur while not being on
> shortest path
>
> I know the feeling if we're generally talking about data structures and
> algorithms, but with regards to language spec, the only mental reference I
> have for "path" is for "import paths" of which the actual name is
> important. Searching the spec for "path" in fact only turns up references
> to import path.
>
> So on sight, I assumed "shortest path" meant changing `Texture` to `Tex`
> would affect resolution, which I also knew to be incorrect. It's my own
> failing but thanks for pointing me in the right direction as I was at a
> loss for where to even start as the visual cue of `type  A B` vs `type A
> struct {B}` didn't register wrt the desired error for me.
>
> On Sun, Nov 5, 2017 at 10:09 AM Jan Mercl <0xj...@gmail.com> wrote:
>
>> I don't know when the shallowest depth can occur while not being on
>> shortest path.  Note that path was used in this discussion as meaning full,
>> unpromoted path, ie. like if every embedded field of type T was declared T
>> T instead. The actual selector expression is a prefix of this full path.
>>
>> On Sun, Nov 5, 2017, 16:59 Daniel Skinner  wrote:
>>
>>> The spec uses "shallowest depth", not "shortest path", as I assume
>>> saying "path" would imply the given names in a selector expression
>>> determine ambiguity when they do not.
>>>
>>> "shallowest depth" makes the error more clear in my sample where if this:
>>>
>>> type Uniform GLUniform
>>>
>>> is changed to this:
>>>
>>> type Uniform struct {
>>> GLUniform
>>> }
>>>
>>> access to the Value fields would now exist at the same depth and produce
>>> the error I was expecting to see.
>>>
>>> https://golang.org/ref/spec#Selectors
>>>
>>> On Fri, Nov 3, 2017 at 5:38 PM Daniel Skinner  wrote:
>>>
 Right, I've misunderstood why this error is thrown, as in what defines
 ambiguity. Text search of spec for "ambig" only yields results for
 composite literals and avoiding ambiguity in conversions while "shortest"
 yields no results and the only recollection of "shortest path wins" phrase
 I have is back when vendor directory was introduced.

 On Fri, Nov 3, 2017 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:

>
> On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:
>
> > https://play.golang.org/p/Y1UxMgNhWx
> >
> > I ran into this today but don't understand why the compiler isn't
> throwing an ambiguous reference error. Maybe I've misunderstood why this
> error is thrown the few times I've seen it.
>
> No ambiguity here. One of the Value(s) is
> sample.Texture.GLTexture.Value and the other one is sample.Uniform.Value
> and the specs say the shortest path wins.
>
> --
>
> -j
>
 --
>>
>> -j
>>
> --

-j

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

Re: [go-nuts] Is something like SIMD "math/vector" planned?

[Sebastien Binet]

David,

I think the plan is to gather experience with math/bits and then devise
something along the lines of a package that could do vectorized operations.

(Also avx1/2 should be in 1.10 so there's that.)

-s

sent from my droid

On Nov 5, 2017 5:20 PM, "David M."  wrote:

> Hi,
>
> I'm interested in high performance applications in Go, and I saw the new
> "math/bits" package. I think it's very nice that the compiler replaces the
> Go implementation with special CPU instructions when the architecture
> supports it.
>
> My question is, is there a plan to do something similar with basic
> arithmetic on small floating point vector types (things like [4]float32)
> implementing them with SSE/AVX/...?
>
> 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.
>

-- 
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] Converting uint to string

[Chun Zhang]

Hi, All, 

I have a group of integers ranging from 1 to 2^32 that are in the format of 
uint32. I know strconv.Itoa(i) or strconv.FormatUint(i) can definitely give 
unique representation of each number. So, I can use it as the index of a 
map[string]interface{}.

However, I am wondering if I use string(i) only, will I get any two numbers 
the same string representation? My guess is no, but would like to get some 
comments from you experts.

Also, will string(i) be faster than strconv.Itoa or strcov.FormatUInt?



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] Converting uint to string

[Jan Mercl]

On Sun, Nov 5, 2017 at 10:09 PM Chun Zhang  wrote:

> I have a group of integers ranging from 1 to 2^32 that are in the format
of uint32.

Assuming you mean 'to 2^32-1'.

> However, I am wondering if I use string(i) only, will I get any two
numbers the same string representation? My guess is no, but would like to
get some comments from you experts.

It's specified
, see
https://play.golang.org/p/70efZ9FgME


-- 

-j

-- 
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] Converting uint to string

[Chun Zhang]

Hi, Jan, 

Thank you very much!!

Best,
Chun

On Sunday, November 5, 2017 at 4:17:43 PM UTC-5, Jan Mercl wrote:
>
> On Sun, Nov 5, 2017 at 10:09 PM Chun Zhang  > wrote:
>
> > I have a group of integers ranging from 1 to 2^32 that are in the format 
> of uint32.
>
> Assuming you mean 'to 2^32-1'.
>
> > However, I am wondering if I use string(i) only, will I get any two 
> numbers the same string representation? My guess is no, but would like to 
> get some comments from you experts.
>
> It's specified 
> , see 
> https://play.golang.org/p/70efZ9FgME
>
>
> -- 
>
> -j
>

-- 
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] Converting uint to string

[John Souvestre]

You could also just the integers themselves as keys.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Chun Zhang
Sent: 2017 November 05, Sun 15:09
To: golang-nuts
Subject: [go-nuts] Converting uint to string

 

Hi, All, 

 

I have a group of integers ranging from 1 to 2^32 that are in the format of 
uint32. I know strconv.Itoa(i) or strconv.FormatUint(i) can definitely give 
unique representation of each number. So, I can use it as the index of a 
map[string]interface{}.

 

However, I am wondering if I use string(i) only, will I get any two numbers the 
same string representation? My guess is no, but would like to get some comments 
from you experts.

 

Also, will string(i) be faster than strconv.Itoa or strcov.FormatUInt?

 

 

 

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.

[go-nuts] append to a stem racy?

[Dan Kortschak]

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

[Dan Kortschak]

With high N, I have been able to confirm raciness.

On Mon, 2017-11-06 at 11:13 +1030, Dan Kortschak wrote:
> I have not been able to get the race detector to complain about this,
> even if I make len << cap.



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

[Chun Zhang]

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*


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] Rationale in docs on why you need to use the result of append()

[Dave Cheney]

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

[Tamás Gulácsi]

What if you use stem[:len(stem):len(stem)] as the stem? 

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

[Tamás Gulácsi]

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.

[go-nuts] [Request] Official golang debugger

[Sotirios Mantziaris]

Hi,

with the lack of a official debugger, i  am using delve.
It is very nice and get the work done mostly, needs little or a lot of 
polishing.
Is there any plan to provide a official debugger which will be distributed 
with the releases?
Maybe delve could make it as the official one?

Do not get me wrong, delve is fantastic. Kudos to @derekparker and the 
contibutors for delve .

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

[2891132love]

Sorry, the last program is about server.and the following program is about 
the client:

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", os.Args[0])
}
 service := os.Args[1]
 tcpAddr, err := net.ResolveTCPAddr("tcp", service)
 checkError(err)
 conn, err := net.DialTCP("tcp", nil, tcpAddr)
 checkError(err)
 rAddr := conn.RemoteAddr()
 n, err := conn.Write([]byte("hello server!"))
 checkError(err)
 n, err = conn.Read(buf[0:])
 checkError(err)
 fmt.Println("reply from server", rAddr.String(), string(buf[0:n]))
 conn.Close()
 os.Exit(0)
   }
func checkError(err error) {
 if err != nil {
  fmt.Fprintf(os.Stderr, "fatal error: %s", err.Error())
  os.Exit(0)
   }
}


the questoin is how to make the client communicate with the server??I want 
to see the message can be showed on the screen. Can these  programs  run in 
the same computer??if so,How to make it?? 

在 2017年10月30日星期一 UTC+8下午2:55:27，28911...@gmail.com写道：

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

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