[go-nuts] Vendor compilation problem

[Dave Cheney]

Can you please provide the output from running to eng. 

It looks like your GOPATH variables is either not set, or not set to the 
correct value, which looks to be in this case

/home/vuco/repos/gopkg

-- 
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] Vendor compilation problem

[Dave Cheney]

Hi,

Can you please provide the output from running,

go env

It looks like your GOPATH variables is either not set, or not set to the 
correct value, which in this case looks to be,

/home/vuco/repos/gopkg

-- 
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] Conditional compiling for android

[Dave Cheney]

The build system considers android and Linux to be the same for historical 
reasons. 

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

[go-nuts] net.Pipe doesn't support deadlines

[Dave Cheney]

Which version of Go are you using?

https://github.com/golang/go/blob/master/src/net/pipe.go#L224

-- 
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: Why is there no standard `uuid` package?

[Dave Cheney]

But that’s the problem, who’s default uuid format is chosen? And how to justify 
this over the other users who want their default to be chosen. 

The answer is as it currently stands, multiple uuid libraries exist outside the 
standard library. 

Can you tell me, in concrete terms, what are the benefits to you of a (I’m 
going to assume the one that is compatible with your project) uuid 
implementation being included in the standard library. 

-- 
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: Why is there no standard `uuid` package?

[Dave Cheney]

Your argument that the stdlib grows a uuid package is really a call for 
stability. “3rd parties cannot provide us the stability we need, so the go team 
must”. I don’t think that is a fair expectation on the go team, especially as 
there is no clear standard for what a uuid is (having multiple inplemebtations 
pushes the discussion into the domain of the python standard library). 

I think your problems would be best solved by forking the uuid library at a 
revision that works for you, or sponsoring the development of a sufficiently 
stable uuid library. There is clearly a market for one. 

-- 
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: is there an atexit?

[Dave Cheney]

Your program has a data race in the exitcode variable. 

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

[Dave Cheney]

cgo is not 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.

[go-nuts] Re: All Forms of Wishful Generics

[Dave Cheney]

I certainly don’t want what happened to C++ to happen to Go. If it’s a choice 
between obsolescence or being crushed under the weight of self inflicted 
complexity, I’ll gladly vote with my feet for the former. 

-- 
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] About Go Compiler!

[Dave Cheney]

In Go 1.4 the project contained both .go files and .c files. It shipped 
with two compilers, a go compiler, called gc, and a c compiler called cc.

> /go/src/cmd/gc/go.y

This is the input file for the yacc grammar for the Go 1.4 go compiler 

> /go/src/cmd/cc/cc.y

This is the input file for the yacc grammar for the Go 1.4 c compiler 

The same advice applies to the other two files you mentioned.

On Monday, 19 February 2018 09:57:21 UTC+11, Compiler wrote:
>
> yeah , in go1.4 version,i want know difference between files.
> ?!
>
> On Monday, February 19, 2018 at 2:04:09 AM UTC+3:30, Ian Lance Taylor 
> wrote:
>>
>> On Sun, Feb 18, 2018 at 9:23 AM, Compiler  wrote: 
>> > #Question 
>> > 
>> > What is the difference between using the following two files? 
>> > 
>> > /go/src/cmd/gc/go.y 
>> > /go/src/cmd/cc/cc.y 
>> > 
>> > - 
>> > #Question 
>> > 
>> > What is the difference between using the following two files? 
>> > 
>> > /go/src/cmd/gc/lex.c 
>> > /go/src/cmd/cc/lex.c 
>>
>> You must be looking at a very old version of Go, as current versions 
>> of Go do not contain either file. 
>>
>> Old versions of Go shipped with a C compiler that was used to build 
>> parts of the runtime that were written in C.  Those parts were 
>> rewritten into Go, and Go no longer ships a C compiler.  Back then, 
>> the Go compiler was in cmd/gc and the C compiler was in cmd/cc. 
>>
>> 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] About Go Compiler!

[Dave Cheney]

I feel like we’ve had this same discussion a few months ago.

Ian has mentioned that go 1.4 is no longer in use (it exists only in a very 
special case or bootstrapping from source).

Can you please give some context to your questions so we may assist you better.

-- 
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] About Go Compiler!

[Dave Cheney]

> what files require the c compiler?

The c files in the go 1.4 distribution. 

-- 
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] About Go Compiler!

[Dave Cheney]

> which files require go-c compiler?

The ones in the go 1.4distributuon that end in .c. 

-- 
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] About Go Compiler!

[Dave Cheney]

yes, up to Go 1.4, part of the go runtime was compiled using a c compiler 
which derived from the plan 9 c compilers. In fact, the c frontend and the 
go frontend shared the same code generation backends.

On Monday, 19 February 2018 10:31:35 UTC+11, Compiler wrote:
>
> mean all `.c` file in /src/ compile using own c-compiler?!
>
> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>
>> > which files require go-c compiler?
>>
>> The ones in the go 1.4distributuon that end in .c. 
>>
>

-- 
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] About Go Compiler!

[Dave Cheney]

On Monday, 19 February 2018 10:33:16 UTC+11, Compiler wrote:
>
> /go/src/cmd/cc/
> this directory is base of c-compiler.
>

yes, that is where the shared parts of the c compiler lives, the 
architecture specific parts were in 5c, 6c, 8c, etc.
 

>
> so not `.c` file in /src/.
>

You can answer this question yourself by looking in the tarball. The Go 1.4 
runtime was written in a mixture of Go, C, and Assembly. 

>
> On Monday, February 19, 2018 at 3:01:35 AM UTC+3:30, Compiler wrote:
>>
>> mean all `.c` file in /src/ compile using own c-compiler?!
>>
>> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>>
>>> > which files require go-c compiler?
>>>
>>> The ones in the go 1.4distributuon that end in .c. 
>>>
>>

-- 
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] About Go Compiler!

[Dave Cheney]

In theory, yes. In practice, I doubt it.

On Monday, 19 February 2018 10:37:14 UTC+11, Compiler wrote:
>
> Can build only c(own) compiler using a c compiler(like gcc) without go 
> from this source?!
>
>
> On Monday, February 19, 2018 at 2:48:26 AM UTC+3:30, Dave Cheney wrote:
>>
>> I feel like we’ve had this same discussion a few months ago. 
>>
>> Ian has mentioned that go 1.4 is no longer in use (it exists only in a 
>> very special case or bootstrapping from source). 
>>
>> Can you please give some context to your questions so we may assist you 
>> better.
>
>

-- 
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] About Go Compiler!

[Dave Cheney]

On Monday, 19 February 2018 10:42:12 UTC+11, Compiler wrote:
>
> Assembly?!
> but not exist many `.asm` files at source.
>

By tradition assembly files have .s and .S extensions
 

> Also, I had already asked ...
>

Already asked what? It might be easier if you give more background to the 
_problem_ you want to solve rather than asking random questions without 
context.
 

> And they said they were not with the assembly and is generate executable 
> file using object file.
>

Who is they? Can you give some more context.
 

>
> On Monday, February 19, 2018 at 3:08:51 AM UTC+3:30, Dave Cheney wrote:
>>
>>
>>
>> On Monday, 19 February 2018 10:33:16 UTC+11, Compiler wrote:
>>>
>>> /go/src/cmd/cc/
>>> this directory is base of c-compiler.
>>>
>>
>> yes, that is where the shared parts of the c compiler lives, the 
>> architecture specific parts were in 5c, 6c, 8c, etc.
>>  
>>
>>>
>>> so not `.c` file in /src/.
>>>
>>
>> You can answer this question yourself by looking in the tarball. The Go 
>> 1.4 runtime was written in a mixture of Go, C, and Assembly. 
>>
>>>
>>> On Monday, February 19, 2018 at 3:01:35 AM UTC+3:30, Compiler wrote:
>>>>
>>>> mean all `.c` file in /src/ compile using own c-compiler?!
>>>>
>>>> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>>>>
>>>>> > which files require go-c compiler?
>>>>>
>>>>> The ones in the go 1.4distributuon that end in .c. 
>>>>>
>>>>

-- 
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] About Go Compiler!

[Dave Cheney]

Stop.

What do you want to do?

Do you want to write a C compiler ?

On Monday, 19 February 2018 10:47:24 UTC+11, Compiler wrote:
>
> https://groups.google.com/forum/#!topic/golang-nuts/24pSm-B3FqU
>
> On Monday, February 19, 2018 at 3:14:48 AM UTC+3:30, Dave Cheney wrote:
>>
>>
>> Who is they? Can you give some more context.
>>
>

-- 
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] About Go Compiler!

[Dave Cheney]

If you want to learn more about the Go compiler then you must stop living 
in the past. Go 1.4 is _dead_. The current compiler is written in pure go 
and you can find the sources 
here https://github.com/golang/go/tree/master/src/cmd/compile/internal

We cannot help you use the old Go 1.4 c compiler to write a compiler. 
Someone may want to pursue that as a project, but not on this mailing list. 
This mailing list is for talking about Go. 

On Monday, 19 February 2018 10:59:32 UTC+11, Compiler wrote:
>
> I have some experience in writing lexer,parser,interpreter,optimize.
> I've also worked generate output code(example one language to another).
>
> currently example i'm design a interpreter and for final step( generate 
> output file) using another compiler.
>
> i'm want know more about compiler... and trying them.
>
> I mean the compiler : self compiler
>
> On Monday, February 19, 2018 at 3:22:27 AM UTC+3:30, Dave Cheney wrote:
>>
>> Stop.
>>
>> What do you want to do?
>>
>> Do you want to write a C compiler ?
>>
>> On Monday, 19 February 2018 10:47:24 UTC+11, Compiler wrote:
>>>
>>> https://groups.google.com/forum/#!topic/golang-nuts/24pSm-B3FqU
>>>
>>> On Monday, February 19, 2018 at 3:14:48 AM UTC+3:30, Dave Cheney wrote:
>>>>
>>>>
>>>> Who is they? Can you give some more context.
>>>>
>>>

-- 
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] About Go Compiler!

[Dave Cheney]

I recommend watching this presentation from Russ Cox about why the Go team 
decided to rewrite the compiler from C to Go. 

https://www.youtube.com/watch?v=QIE5nV5fDwA

On Monday, 19 February 2018 11:44:23 UTC+11, Compiler wrote:
>
> Performance of C with Optimize not better of Go at more time?!
> so why re-write golang in go?
>
> On Monday, February 19, 2018 at 3:54:08 AM UTC+3:30, Compiler wrote:
>>
>> When Golang using *bootstrapping **technique* , performance not Decrease?
>>
>> On Monday, February 19, 2018 at 3:42:18 AM UTC+3:30, Compiler wrote:
>>>
>>> *bootstrapping* is the technique for producing a self-compiling compiler 
>>> 
>>>
>>> On Monday, February 19, 2018 at 3:40:54 AM UTC+3:30, Compiler wrote:

 whats difference between self-hosting compiler vs Bootstrapping 
 compiler?

 https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

 On Monday, February 19, 2018 at 3:34:48 AM UTC+3:30, Michael Jones 
 wrote:
>
> much better!  i suggest Google searches about bootstrapping, 
> self-hosting, and security.
>


-- 
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: Dero: CryptoNote protocol + smart contracts using golang

[Dave Cheney]

Is there a reason DERO chose to go with their own licence rather than a 
BSD, MIT, or Apache 2 licence?


On Monday, 19 February 2018 16:10:14 UTC+11, 867crypt...@gmail.com wrote:
>
> Hello, my name is Serena, I’m the Community Manager at a blockchain 
> project called Dero. We use a protocol called CryptoNote that was 
> originally written in C++. The developers at the Dero Project have 
> rewritten most of the (CryptoNote) codebase to golang and we would like to 
> start some discussion within the development and open source communities.
>
>
> The core cryptography and functionally (rewritten in golang) is working 
> and available on GitHub for limited evaluation and testing. We would 
> genuinely value the feedback from this community. The following is what 
> I’ve posted to a couple other communities as well. (I would like to 
> emphasize that this project is currently pre-alpha but your input (the 
> google community) in particular is important to us.)
>
>
> *DERO: Privacy + Smart Contracts*
>
>
> Dero at present is a code fork of Monero (Helium Hydra) with the Bytecoin 
> CryptoNote protocol.
>
> Dero will be a completely new blockchain technology integrating the 
> CryptoNote protocol with new smart contract controls.
>
> *Dero is being rewritten from C++ to Golang (Google Language) to bring 
> together CryptoNote and smart contracts on the Dero blockchain.*
>
>
> *CryptoNote protocol implementation in Golang is almost completed and 
> available on GitHub for basic testing/evaluation.*
>
>
> *GitHub:* https://github.com/deroproject/derosuite (Golang version for 
> testing purposes only at this time)
>
>
> *Bitcointalk:* https://bitcointalk.org/index.php?topic=2525508.0
>
>
> Dero has a very welcoming community and we would enjoy the opportunity to 
> have you join us!
>
>
> *FULL DISCLOSURE:Dero has a very welcoming community and we would enjoy 
> the opportunity to have you join us!*
>
>
> *FULL DISCLOSURE:* My name is Serena, I’m the Community Manager at the 
> Dero Project
>

-- 
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: Build started to fail with 1.10

[Dave Cheney]

The failing line was added in december last year,

https://github.com/golang/go/commit/7cba779cea5#diff-56c7df71bce32f8e50115128ae30941eR13

This also adds a dependency on time.h. Is time.h available in your build 
container?

On Friday, 23 February 2018 20:09:02 UTC+11, Владислав Митов wrote:
>
> Nah, it's not that - https://travis-ci.org/miracl/gomiracl/jobs/345158452. 
> If fails also in golang:latest where the yaml gotcha it's not a thing. 
> Solid suggestion though, thanks.
>
> On Friday, February 23, 2018 at 11:02:59 AM UTC+2, Владислав Митов wrote:
>>
>> Ah, I read about that but ti says `go version go1.10 linux/amd64`. I'll 
>> try putting it in quotes now.
>>
>> On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:
>>>
>>> This is almost certainly because your .travis file is specifying your 
>>> version as `1.10` vs `"1.10"`
>>>
>>> So your build is building with go 1.1 instead of 1.10.
>>>
>>> Ran into this myself this morning.
>>>
>>> -Nic
>>>
>>> On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов 
>>> wrote:

 Hey guys, 

 One of my build started failing with 1.10. Basically I'm building a 
 wrapper around a C library and it fails with: 

 # runtime/cgo
 gcc_libinit.c: In function '_cgo_try_pthread_create':
 gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
   struct timespec ts;
   ^~
 gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
 [-Werror=implicit-function-declaration]
nanosleep(&ts, nil);
^
 gcc_libinit.c:97:18: error: unused variable 'ts' 
 [-Werror=unused-variable]
   struct timespec ts;
   ^~
 cc1: all warnings being treated as errors
 https://travis-ci.org/miracl/gomiracl/jobs/344782123

 Any hint's what's causing this? 

 Cheers, 
 Vladi

>>>

-- 
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 this a bug?

[Dave Cheney]

Type C conforms to the T1 interface?

What did you expect?

-- 
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 interpret runtime._ExternalCode in a profile?

[Dave Cheney]

I don't understand how that could happen. time.Now calls time.now (which is 
in assembly) so the former shouldn't be inlined, or omitted from profiling.

On Monday, 26 February 2018 14:02:13 UTC+11, Caleb Spare wrote:
>
> On a hunch, I profiled a benchmark which just calls time.Now in a loop. 
> Indeed: 95% of the time is attributed to runtime._System -> 
> runtime._ExternalCode.
>
> My program does collect a lot of timing information as it runs and ends up 
> calling time.Now quite a lot. I don't yet know for sure that most/all of 
> the runtime._ExternalCode that shows up in my program's profile is 
> time.Now, but that wouldn't surprise me.
>
> This makes me curious: would it be feasible to make the profiler recognize 
> a vDSO call and synthesize a more helpful stack?
>
> On Sun, Feb 25, 2018 at 3:39 PM, Ian Lance Taylor  > wrote:
>
>> On Sun, Feb 25, 2018 at 3:30 PM, Caleb Spare > > wrote:
>>
>>> There's no cgo in this program or any of its non-stdlib dependencies.
>>>
>>> The server is a static binary built with CGO_ENABLED=0.​ Can there still 
>>> be cgo code running somehow?
>>>
>>
>> No, if it's CGO_ENABLED=0, then I think cgo code can not be the problem.
>>
>> But I also can't think of any other plausible reason to have so many hits 
>> for this case.  It can happen if the profiling signal is received while 
>> executing in `gogo`, `systemstack`, `mcall`, or `morestack`.  But none of 
>> those occur all that often and they run for a short time.  It's hard to 
>> believe that they would show up when profiling a real program.  I don't 
>> know what is happening here.
>>
>> The code path you are seeing is the `n == 0` case in `sigprof` in 
>> runtime/proc.go.
>>
>> Ian
>>
>>
>>  
>>
>>> On Sun, Feb 25, 2018 at 3:05 PM, Ian Lance Taylor >> > wrote:
>>>
 On Sun, Feb 25, 2018 at 2:01 PM, Caleb Spare >>> > wrote:

> How should I interpret runtime._System calling into 
> runtime._ExternalCode in a pprof profile?
>
> I saw this taking >10% of CPU time, so I recompiled with CGO_ENABLED=0 
> and even so I see 6.62% of time in runtime._ExternalCode.
>
> runtime._System is a root in the graph so I can't even figure out what 
> part of my code this might be related to.
>
> [image: Inline image 1]
>
>
>



 This is what you see when a profililng signal occurs while executing 
 code for which the Go runtime could not generate a traceback, and the 
 thread was not running the garbage collector.  The most common reason for 
 being unable to get a traceback is running in cgo code.

 If you are running on an ELF based system like GNU/Linux then consider, 
 for testing purposes only, importing 
 github.com/ianlancetaylor/cgosymbolizer.  No need to actually use the 
 package for anything, just do a blank import somewhere.  If you're lucky 
 that will give you a more detailed profile.

 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] How to interpret runtime._ExternalCode in a profile?

[Dave Cheney]

Ahh, thank you. That was the missing piece of my understanding. 

-- 
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: constructors vs lazy initialization

[Dave Cheney]

I prefer the later when possible because it enables callers to use the zero 
value of a type without explicit initialisation.

On Sunday, 4 March 2018 11:37:43 UTC+11, Anmol Sethi wrote:
>
> How do you guys choose between constructors and lazy initialization?
>
> For example.
>
> Struct constructors:
>
> type meow struct {
> x http.Handler
> }
>
> func newMeow() *meow {
> return &meow{
> x: http.NewServeMux(),
> }
> }
>
> func (m *meow) do() {
> // stuff
> }
>
>
> Lazy initialization:
>
> type meow struct {
> x http.Handler
> }
>
> func (m *meow) do() {
> if m.x == nil {
> m.x = http.NewServeMux()
> }
> // stuff
> }
>
>

-- 
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] $PATH error.

[Dave Cheney]

Under the hood go get shells out to git to fetch source code. You need to 
install git. 

-- 
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] Pass by value in struct not yielding expected result

[Dave Cheney]

On Wednesday, 7 March 2018 07:39:56 UTC+11, andrey mirtchovski wrote:
>
> maybe this will give you a hint: https://play.golang.org/p/ANIjc3tCdwp 
>
> maps are reference types, but they still get passed by value.
>

Maps are pointers, pointers are values. 

-- 
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: Windows cgo complier

[Dave Cheney]

This windows build dependencies are captured 
here, https://github.com/golang/go/wiki/WindowsBuild

On Thursday, 29 March 2018 00:17:32 UTC+11, Luke Mauldin wrote:
>
> Can someone please tell me what the golang team uses as the reference 
> windows x64 compiler? I have heard references to mingw64 but it would be 
> helpful to know the exact version they are using for their unit tests on 
> Windows. I am experiencing different cgo windows behavior in 1.10 than 
> 1.9.3 and I want to verify I am using the validated windows tool chain.
>
> Luke
>

-- 
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] blocking profiler

[Dave Cheney]

It looks like you’re stopping the block profile immediately after starting it.

Try github.com/pkg/profile which will take care of the plumbing for you. 

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

[go-nuts] Re: Scheduler discrepancy between Linux and OS X with Gosched()

[Dave Cheney]

A printf, especially the first one in the program is likely to cause the 
goroutine going off to the write(2) syscall to block long enough that a new 
thread is created to replace it. Once the original thread comes back from 
the syscall it will find that it has nothing to do, as you set runtime 
Gomaxprocs to one and will be parked by the scheduler.

What your program is doing is sending a bunch of work on an _non blocking_ 
channel then printing the difference between the start time and the end 
time (btw, use t0 := time.Now(); time.Since(t0))

There is nothing in the doWork goroutine that prevents the main goroutine 
from exiting, so as soon as the scheduler is perturbed enough to schedule 
the main goroutine, your program will exit.

The take away:

runtime.Gosched is _not_ guarenteed to transfer control to a runnable 
goroutine, because it is not defined if a send, c <- 0, will transfer 
control to the receiving goroutine or not. If you're lucky then 1000 sends 
will happen without transferring control to doWork. If you are not then 
control is transferred at some point in that 1000, and because you told the 
sending goroutine to sleep for 1 millisecond between sends, when you call 
runtime.Gosched in doWork, the main goroutine was asleep (therefore not 
runnable) so there is nothign to schedule; so you waste another 100ms, then 
try again to reschedule.

Ps. The Go execution tracer will show you what is happening with your 
program. I recommend using it to get a greater understanding of your 
programs behaviour.


On Tuesday, 3 April 2018 14:56:49 UTC+10, brianbl...@gmail.com wrote:
>
> I've run into some mysterious behavior, where Gosched() works as expected 
> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
> statement before it.
>
> I originally posted this on Stack Overflow but was directed here. Post: 
> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>
> Any help would be greatly appreciated! Very curious what's going on here, 
> as this behavior came up while I was trying to write a websocket broadcast 
> server. Here's a minimal setup that reproduces the behavior:
>
> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
> pushes a dummy message onto another goroutine via a channel. The second 
> goroutine listens for new messages, and every time it gets one it does 10ms 
> of work. So without any runtime.Gosched() calls, the program will take 10 
> seconds to run.
>
> When I add periodic runtime.Gosched() calls in the second goroutine, as 
> expected the program runtime shrinks down to 1 second on my Mac. However, 
> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
> made sure to set runtime.GOMAXPROCS(1) in both cases.
>
> Here's where it gets really strange: if I just add a logging statement 
> before the the runtime.Gosched() calls, then suddenly the program runs in 
> the expected 1 second on Ubuntu as well.
>
>
> package main
> import (
> "time"
> "log"
> "runtime")
>
> func doWork(c chan int) {
> for {
> <-c
>
> // This outer loop will take ~10ms.
> for j := 0; j < 100 ; j++ {
> // The following block of CPU work takes ~100 microseconds
> for i := 0; i < 30; i++ {
> _ = i * 17
> }
> // Somehow this print statement saves the day in Ubuntu
> log.Printf("donkey")
> runtime.Gosched()
> }
> }}
>
> func main() {
> runtime.GOMAXPROCS(1)
> c := make(chan int, 1000)
> go doWork(c)
>
> start := time.Now().UnixNano()
> for i := 0; i < 1000; i++ {
> time.Sleep(1 * time.Millisecond)
>
> // Queue up 10ms of work in the other goroutine, which will backlog
> // this goroutine without runtime.Gosched() calls.
> c <- 0
> }
>
> // Whole program should take about 1 second to run if the Gosched() calls 
> // work, otherwise 10 seconds.
> log.Printf("Finished in %f seconds.", float64(time.Now().UnixNano() - 
> start) / 1e9)}
>
>
>

-- 
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: blocking profiler

[Dave Cheney]

I’ve not seen that problem before. I’d hazard a guess that it’s an incorrect go 
installation. Don’t set goroot, basically ever. But it’s just a guess. 

Are you able to create a stand alone program that demonstrates the issue with 
the profile? Please consider raising a bug, golang.org/issue/new

-- 
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: Scheduler discrepancy between Linux and OS X with Gosched()

[Dave Cheney]

> But is it not guaranteed that runtime.Gosched() will at least check if 
another goroutine is runnable?

It checks, but I believe that at the time that it checks there are often no 
other runnable goroutines. The execution tracer will give you the answer to 
this.

On Wednesday, 4 April 2018 04:12:40 UTC+10, brianbl...@gmail.com wrote:
>
> Hi Dave, thanks for the reply!
>
> It makes sense that the send c <- 0 is not guaranteed to transfer control 
> to the receiving goroutine. But is it not guaranteed that runtime.Gosched() 
> will at least check if another goroutine is runnable? I thought that was 
> roughly the point of runtime.Gosched(). 
>
> I see what you're saying in that when the second goroutine calls Gosched, 
> the sleep period may not be finished. But this will only waste another 100 
> microseconds by design (not 100 milliseconds), so it seems like control 
> flow should return to the main goroutine approximately when the sleep call 
> finishes.
>
> I created a simpler example, that doesn't use channels and avoids the work 
> length ambiguity, posted below. Now the secondary goroutine just does an 
> infinite loop of runtime.Gosched(). It should be instantaneous to run (and 
> is on my Mac), but it takes almost exactly 5 seconds on Ubuntu, suggesting 
> that there is some fixed 5 millisecond delay on Gosched(). And adding a 
> print above spin's Gosched makes it instantaneous.
>
> Thanks for your patience! I'm working on an application where the ~5ms 
> Gosched delay is meaningful and I am very curious to figure out what's 
> going on here. 
> package main
>
> import (
> "log"
> "runtime"
> "time"
> )
>
> func spin() {
> for {
> runtime.Gosched()
> }
> }
>
> func main() {
> runtime.GOMAXPROCS(1)
> go spin()
>
> t0 := time.Now()
> for i := 0; i < 1000; i++ {
> time.Sleep(10 * time.Microsecond)
>
> runtime.Gosched()
> }
>
> log.Printf("Finished in %v.", time.Since(t0))
> }
>
>
> On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4, brianbl...@gmail.com 
> wrote:
>>
>> I've run into some mysterious behavior, where Gosched() works as expected 
>> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
>> statement before it.
>>
>> I originally posted this on Stack Overflow but was directed here. Post: 
>> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>>
>> Any help would be greatly appreciated! Very curious what's going on here, 
>> as this behavior came up while I was trying to write a websocket broadcast 
>> server. Here's a minimal setup that reproduces the behavior:
>>
>> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
>> pushes a dummy message onto another goroutine via a channel. The second 
>> goroutine listens for new messages, and every time it gets one it does 10ms 
>> of work. So without any runtime.Gosched() calls, the program will take 
>> 10 seconds to run.
>>
>> When I add periodic runtime.Gosched() calls in the second goroutine, as 
>> expected the program runtime shrinks down to 1 second on my Mac. However, 
>> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
>> made sure to set runtime.GOMAXPROCS(1) in both cases.
>>
>> Here's where it gets really strange: if I just add a logging statement 
>> before the the runtime.Gosched() calls, then suddenly the program runs 
>> in the expected 1 second on Ubuntu as well.
>>
>>
>> package main
>> import (
>> "time"
>> "log"
>> "runtime")
>>
>> func doWork(c chan int) {
>> for {
>> <-c
>>
>> // This outer loop will take ~10ms.
>> for j := 0; j < 100 ; j++ {
>> // The following block of CPU work takes ~100 microseconds
>> for i := 0; i < 30; i++ {
>> _ = i * 17
>> }
>> // Somehow this print statement saves the day in Ubuntu
>> log.Printf("donkey")
>> runtime.Gosched()
>> }
>> }}
>>
>> func main() {
>> runtime.GOMAXPROCS(1)
>> c := make(chan int, 1000)
>> go doWork(c)
>>
>> start := time.Now().UnixNano()
>> for i := 0; i < 1000; i++ {
>> time.Sleep(1 * time.Millisecond)
>>
>> // Queue up 10ms of work in the other goroutine, which will backlog
>> // this goroutine without runtime.Gosched() calls.
>> c <- 0
>> }
>>
>> // Whole program should take about 1 second to run if the Gosched() 
>> calls 
>> // work, otherwise 10 seconds.
>> log.Printf("Finished in %f seconds.", float64(time.Now().UnixNano() - 
>> start) / 1e9)}
>>
>>
>>

-- 
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: blocking profiler

[Dave Cheney]

You can report issues with Go at this link, golang.org/issue/new. 

However, this looks like a docker weirdness so we cannot help you as the 
bug isn't in go, it's docker weirdness.

Please try their support forums, sorry I don't have those details, i've 
never tried to get support for their product.

On Wednesday, 4 April 2018 21:52:08 UTC+10, sothy shan wrote:
>
>
>
> On Tuesday, April 3, 2018 at 4:50:36 PM UTC+2, Dave Cheney wrote:
>>
>> I’ve not seen that problem before. I’d hazard a guess that it’s an 
>> incorrect go installation. Don’t set goroot, basically ever. But it’s just 
>> a guess. 
>>
> It is basically problem when I run in docker container. This is sample 
> program.
>
> ++
> package main
>
> import (
> "os"
> "runtime/pprof"  
> "runtime"
> "fmt"   
> ) 
>
> func main() {
> f,_ :=os.Create("./ipcore_blocking.prof")
> 
>  runtime.SetBlockProfileRate(1)
>   
>   defer func() {
> if err := pprof.Lookup("block").WriteTo(f,0); err 
> !=nil {
> fmt.Printf("blocking profiler statistic 
> collecition initialization failed: %v", err)
>  }
>
>  f.Close()
>  runtime.SetBlockProfileRate(0)
>}()  
> // create new channel of type int
> ch := make(chan int)
>
> // start new anonymous goroutine
> go func() {
> // send 42 to channel
> ch <- 42
> }()
> // read from channel
> <-ch
> }
> +
> When I run localhost, it workes well. when I tries to run docker 
> container, it didnt work. I can give my dockerfile here. 
> FROM golang:1.9-alpine as dev
>
> +++
> RUN apk add --no-cache --repository 
> http://dl-3.alpinelinux.org/alpine/edge/community upx
>
> WORKDIR /go/src/project
>
>
> COPY ./main.go /go/src/project
> RUN go build -o /bin/project
>
> FROM scratch
> COPY --from=dev /bin/project /bin/project
> ENTRYPOINT ["/bin/project"]
>  
> +
> I have another problem when I run in Docker with CPU profile. 
>
> In this case where to report the issues?
>
> Best regards
> Sothy
>
>>
>> Are you able to create a stand alone program that demonstrates the issue 
>> with the profile? Please consider raising a bug, golang.org/issue/new
>
>

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[Dave Cheney]

Indeed. Please do not conflate popularity with ubiquity. Formula one is a very 
popular sport, but not everyone needs to do 180mph down the straight away for 
their daily commute. 

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

[go-nuts] Why isn't os.File an interface?

[Dave Cheney]

Please have a read of my talk on solid from 2016. 

https://dave.cheney.net/2016/08/20/solid-go-design

Tldr: define an interface with the behaviour of the os.File that your 
function/method expects. 

-- 
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] Fancy Comments & Documentation

[Dave Cheney]

Try putting a blank line between your comment block and the next symbol. This 
will break the association between the comment block and the symbol and hide 
the former. 

-- 
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] schollz/peerdiscovery - Pure-Go library for cross-platform local peer discovery using UDP broadcast

[Dave Cheney]

Looking at the code for Discover it is possible you are discarding several 
errors whose contents may explain the issue you see on windows. 

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

[go-nuts] how do i upgrade to latest version of go?

[Dave Cheney]

It depends on how you installed ypthe previous version of go. Home brew is 
popular on the Mac so follow their instructions for upgrading a package 
installed via brew. 

If you used one of the options from the golang org website, simply remove 
/usr/local/go and follow the instruction on the website to install go 1.10.1. 

Lastly, unset GOROOT if you’ve set it.

-- 
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 list returning directory starting with underscore on Ubuntu

[Dave Cheney]

If the path start with _ then it is not within the list of directories in your 
GOPATH. 

-- 
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 does time reported by go test relate to the wall clock time?

[Dave Cheney]

Try upgrading to go 1.10. You’ll get build and test caching for free and you’ll 
see a small variance between the timings you reported. 

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

[Dave Cheney]

The leak is here

httpClient := &http.Client{Timeout: timeout, Transport: &http.Transport{Dial
: dialer.Dial}}

If the httpClient value goes out of scope the connections attached to that 
will leak, along with their associated goroutines.

On Monday, 30 April 2018 07:56:43 UTC+2, Tamás Gulácsi wrote:
>
> Where do you Close the dialer? Why aren't you reusing the httpClient?

-- 
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: Windows OneDrive issue ..

[Dave Cheney]

This is issue https://github.com/golang/go/issues/22579

On Tuesday, 1 May 2018 20:38:26 UTC+2, xiof...@gmail.com wrote:
>
> I just discovered a problem running/compiling files that are 
> accessed/backed up by windows OneDrive
>
> (don't know when this started - worked a couple of months ago..)
>
> So I have a simple go file at
>
> C:\Users\xiool\OneDrive\go ie test.go
>
> At the command line all variants of
>
> go run C:/Users/xiool/OneDrive/go/test.go
>
> give the error
>
> package main: cannot find package "." in:
> C:\Users\xiool\OneDrive\go
>
> The files are stored offline on the computer, and simple replacements such 
> as 
>
> notepad.exe C:/Users/xiool/OneDrive/go/test.go
>
> Work as expected
>
>
> Build/install etc also fail. No issues outside the OneDrive directory. And 
> no issues a few months back.
>
> I assume this is a windows problem .. but what ??
>
> Anyone else had this.. and a fix please ??
>

-- 
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: go 1 on Ubuntu 18.04

[Dave Cheney]

Top tip: you never need to set GOROOT. Please don’t set GOROOT, it’ll just 
cause confusing errors for you in the future. 

-- 
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: go 1 on Ubuntu 18.04

[Dave Cheney]

Please allow me to clarify, anyone other than Jan never needs to set GOROOT. 

-- 
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: Go license and fitness for purpose

[Dave Cheney]

Thank you to all those who contributed to this thread. While many Go 
programs are written under open source licences, and many Go programmers 
contribute to open source in a professional or personal capability, it is 
now time to bring the discussion to a close as this thread has moved 
outside the scope of this mailing list.

Please feel free to continue this discussion in other forums.

Thanks

Dave

On Friday, 18 May 2018 05:39:59 UTC+10, matthe...@gmail.com wrote:
>
> Thanks for responding Michael.
>
> "decorative item not to be used off-road, in uneven terrain, or relied 
>> upon as protection in case of vehicle roll."
>
>
> The sticker I’ve been looking at says something like “modifying or 
> attaching anything to this ROPS will compromise the structure and may cause 
> injury or death” and I had a relative roll a tractor last year but is 
> luckily ok.
>
> I understand being conservative for the courts, but GCC and Go can make 
> programs for computers that can do safety applications reliably. People 
> maybe do with GCC derivatives. People do with Ada or C (and Go maybe is 
> less mistake-prone than C at the language level).
>
> Leveraging the work of an open or free project and contributing back 
> improvements found in testing seems like a good idea to me for liable 
> ventures and for the reliability of minimal liability uses that Google does 
> with Go and maybe GCC. I don’t think these compiler projects should take on 
> unnecessary liability, but one thing that can be done is to be sure there 
> aren’t any intentional mistakes, backdoors, or practical jokes as allowed 
> under the licenses. I'd like to guarantee that to liable ventures and it's 
> a free win for general purpose computing anyway.
>
> Matt
>
> On Thursday, May 17, 2018 at 12:18:30 PM UTC-5, Michael Jones wrote:
>>
>> perhaps some context will make this clearer. no reference is being made 
>> to any actual persons or events.
>>
>> 1. It is the observed habit of people (plaintiff's) bring suit in court 
>> when something goes wrong. 
>> Ex: airplane crash, dark spot on potato chip, food is too hot, etc.
>>
>> 2. Plaintiff's attorneys have developed the habit of including everyone 
>> possible in the "bag guy" list; this creates a kind of mutual fund where 
>> everyone can settle for $10,000 and that, multiplied by 100 defendants, is 
>> $1M. The attorney gets 1/3 of that, so attorneys drive nice cars and fly 
>> first class.
>> Ex: car accident with fire.: sue the car company, the airbag company, the 
>> brake pad company, the glass company, the bumper designer, , the gas 
>> station, the gas transport truck, the oil refinery,...,the tire company, 
>> the person who designed the tire treads, etc.
>>
>> 3. After 60+ years of this, everyone who is wise to the situation sells 
>> retail products that specifically disclaim every possible dangerous use, 
>> and as many kinds of critical or life-safety misuse as can be foreseen, and 
>> wholesale products where every possible liability passes to the purchaser 
>> as a condition of sale. 
>> Ex: "You agree to not use the APIs for any activities where the use or 
>> failure of the APIs could lead to death, personal injury, or environmental 
>> damage (such as the operation of nuclear facilities, air traffic control, 
>> or life support systems)."
>>
>> 4. After 40+ years of open source having an observable footprint, open 
>> source entities, corporate contributors, and individuals have found that 
>> this style of "universal disclaimer" is an important defensive bulwark. 
>> Most people would not want to lose their house and savings as the result of 
>> contributing code to a matrix library that happens to be used in the 
>> science payload of a space project where the rocket engines explode on 
>> launch and the resulting fires and fumes cause problems for miles around 
>> resulting in a class-action suit for much of Florida. (crazy made-up 
>> example but perhaps it makes clear the idea of minimizing exposure to legal 
>> risks associated in no logical way with individual action.)
>>
>> This is the context in which various excuse-laden, 
>> suitability-disclaiming, crazy-seeming license agreements arise.
>>
>> As a real example, but with the name removed, I once saw in a parking lot 
>> a new pickup truck made by a well-known Japanese car manufacturer. It had a 
>> shiny chrome tubular framework rising up from the bed of the truck just 
>> behind the cab. The framework had lights attached. It have the truck a 
>> tough, off-road character. I said to my wife, "wow, that's quite the 
>> roll-bar for a little truck. Look how thick the tubes are." She said, there 
>> is a sticker on it what does it say. We looked, it read:  "decorative item 
>> not to be used off-road, in uneven terrain, or relied upon as protection in 
>> case of vehicle roll."
>>
>> That is the real world of litigious people, 1/3 hungry attorneys, and 
>> juries that like to "do something" when there is a victim.
>

[go-nuts] Re: How can I get the last followed URL use http.Client on 302 Redirections?

[Dave Cheney]

Please keep in mind that the Via header is supplied by he client (the browser) 
and there is not requirement that it maintains the full chain of custardy of 
all the urls it has passed though, nor is there any way for Go to know nor 
enforce that this list remains accurate. Sorry. 

-- 
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] Performance hit when using goroutine

[Dave Cheney]

The best tool to investigate this problem is the execution tracer. It will show 
you the activity of goroutines over time making is easy to spot contention. 

-- 
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] Performance hit when using goroutine

[Dave Cheney]

The execution tracer will show this as it tracks resources that goroutines 
block on. 

Seriously I’m just going to keep suggesting the execution tracer until you try 
it :)

-- 
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 should I avoid - literal copies lock value from

[Dave Cheney]

Pass a pointer, *Set into your Diff method. 

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

[go-nuts] buffer.WriteString Error case

[Dave Cheney]

So that it can be used interchangeably with *bufio.Writer. 

-- 
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 go1.10.3 fatal error: runtime: netpoll failed

[Dave Cheney]

As Ian explained on the GitHub issue you raised, RHEL5 is not supported by any 
version of Go - the 2.6.18 kernel is below our minimum requirements. 

Dave

-- 
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 signal(sigint) blocking goroutine

[Dave Cheney]

The context value you pass into record isn't used and running record in its 
own goroutine doesn't really add anything because the main goroutine just 
waits for the other goroutine to exit. The exit the second goroutine will 
be at least 1 second, but could be much longer.

On Saturday, 11 August 2018 12:54:08 UTC+10, natea...@gmail.com wrote:
>
> Thanks for all the comments.  I did finally figure it out.  
> https://play.golang.org/p/ghCT6DCDLJz
>
> On lines 69-70 changed that code from and exec.Command to exec.Start 
> allowing me to sleep for the desired amount of time and then signal(sigint) 
> the command via cmd.Process.Signal(syscall.SIGINT) 
>
> Nate
>
> On Thursday, August 9, 2018 at 9:51:53 PM UTC-4, natea...@gmail.com wrote:
>>
>> https://play.golang.org/p/mr58JS4WsJV
>>
>> Okay, I realize now that I didn't do a very good job in my first post of 
>> explaining my problem, so I'll trying again.  In the above code I need to 
>> signal(sigint or sigterm) the exec.CommandContext on line 69 that is 
>> blocking so it will stop and finish the goroutine.  The goal behind the 
>> code is to set a record duration and then stop the blocking command after 
>> the record timer has been met and exit the goroutine normally.  So far I 
>> haven't been able to figure out how to signal the command to stop.  I have 
>> two tuners that can be recording a the same time, so I need them running in 
>> goroutines so the main thread can do other things.  I read through the 
>> context package that you recommended, but still can't get it to work. 
>>
>> Thanks
>>
>> On Wednesday, August 8, 2018 at 12:20:11 AM UTC-4, Ian Lance Taylor wrote:
>>>
>>> On Tue, Aug 7, 2018 at 7:02 PM,   wrote: 
>>> > 
>>> > https://play.golang.org/p/d5n9bYmya3r 
>>> > 
>>> > I'm new to the go language and trying to figure out how to sigint a 
>>> blocking 
>>> > goroutine.  in the playground code I included an infinite for loop to 
>>> > simulate the blocking. In my real world use the for block would be a 
>>> long 
>>> > running file save from an external device.  I appreciate any advice or 
>>> > direction that is given. 
>>>
>>> I'm not sure quite what you mean, but in general you can not send a 
>>> signal to a goroutine in Go.  Goroutines are not threads.  If you want 
>>> a goroutine to be interruptible, you must write the goroutine to check 
>>> whether something is trying to interrupt it; the standard library's 
>>> "context" package is often used for this purpose. 
>>>
>>> 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] Re: Cross-compiled program for Raspberry Pi crashes

[Dave Cheney]

This is likely to be 
issue https://github.com/golang/go/issues/599, 
https://play.golang.org/p/zZm-6zWwFoi

On Monday, 13 August 2018 01:29:43 UTC+10, Stephan Mühlstrasser wrote:
>
> Hi,
>
> I'm developing my first Go program that is supposed to upload files into a 
> Google Cloud Storage bucket from a Raspberry Pi 1. It uses the 
> https://github.com/blackjack/webcam library to grab a picture from an USB 
> camera.
>
> I can compile the program on the Raspberry Pi itself with Go 1.7.4 that 
> comes with Raspbian, and then it works as expected. However compilation on 
> the Raspberry Pi is slow and it even sometimes fails because of memory 
> shortage. Therefore I want to cross-compile on Windows.
>
> When I cross-compile the exact same source on Windows for ARM with Go 
> 1.10.3, then this binary crashes at some point on the Raspberry Pi with a 
> segmentation fault:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x11520]
>
>
> goroutine 8 [running]:
> sync/atomic.addUint64(0x1236210c, 0x8a75f371, 0xa3f9cbd6, 0xdcd30e9, 
> 0xda39e1c1)
> C:/Go/src/sync/atomic/64bit_arm.go:31 +0x4c
> go.opencensus.io/trace.(*defaultIDGenerator).NewSpanID(0x123620f0, 0x0, 
> 0x0)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:483 +0x50
> go.opencensus.io/trace.startSpanInternal(0x123202d0, 0x22, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0, 0x0, ...)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:196 +0x7c
> go.opencensus.io/trace.StartSpan(0x4c4128, 0x12795c60, 0x123202d0, 0x22, 
> 0x123798ec, 0x2, 0x2, 0x10, 0x40, 0x58f74)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:162 +0x128
> ...
>
> I'm a Go newbie, and therefore I'm not sure how to interpret this. May 
> this be a bug in the Go cross-compiler, or may this be a bug in the program 
> that only manifests itself when the program is cross-compiled with the 
> newer compiler on Windows?  How can I analyze this?
>
> Thanks
> Stephan
>

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

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

[Dave Cheney]

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

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

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

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

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

[Dave Cheney]

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

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

[go-nuts] Re: Extending deadline for logging

[Dave Cheney]

On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>
> As an example:
> Client calls MyService with a deadline of 10 seconds.
> MyService calls OtherService as part of responding. However, the call to 
> OtherService times out due to the deadline in 10 seconds.
> MyService tries to log the error to Spanner; but it's still using that 
> context deadline which expired.
>
> Is there a way to get a new context with an extended deadline? Are there 
> any issues with that approach?
>

Sure, just call context.WithDeadline(context.Background()) and use that 
instead

 The difficulty is you want the deadline of this new context to live beyond 
its parent. Logically it feels like this new context is subordinate to the 
previous, but by design we've said that the new context is _not_ 
subordinate -- the deadline does not apply to it. I think you need to 
address this incongruousness before proceeding.
 

>
>
> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>>
>> I'm working on a service that write some log info to spanner when it's 
>> done responding to a request. 
>> However, the service uses the context's deadline to write to spanner, so 
>> if the deadline expires due to some long running RPC, the write to spanner 
>> fails (because the deadline expired), and we don't get any log info.
>>
>> What's the best practice for dealing with this situation?
>>
>

-- 
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: Extending deadline for logging

[Dave Cheney]

What would happen if you write the error to spanner with a setting
context.Backgrond(), ie, no deadline?

On 16 August 2018 at 13:57, Robert Bartoszynski  wrote:
> Thanks. Perhaps an alternative would be for me to create a child context
> with a deadline of (context - x seconds) and pass that to OtherService, with
> the expectation that there should be x seconds left over for the write to
> spanner.
>
> On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote:
>>
>>
>>
>> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>>>
>>> As an example:
>>> Client calls MyService with a deadline of 10 seconds.
>>> MyService calls OtherService as part of responding. However, the call to
>>> OtherService times out due to the deadline in 10 seconds.
>>> MyService tries to log the error to Spanner; but it's still using that
>>> context deadline which expired.
>>>
>>> Is there a way to get a new context with an extended deadline? Are there
>>> any issues with that approach?
>>
>>
>> Sure, just call context.WithDeadline(context.Background()) and use that
>> instead
>>
>>  The difficulty is you want the deadline of this new context to live
>> beyond its parent. Logically it feels like this new context is subordinate
>> to the previous, but by design we've said that the new context is _not_
>> subordinate -- the deadline does not apply to it. I think you need to
>> address this incongruousness before proceeding.
>>
>>>
>>>
>>>
>>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>>>>
>>>> I'm working on a service that write some log info to spanner when it's
>>>> done responding to a request.
>>>> However, the service uses the context's deadline to write to spanner, so
>>>> if the deadline expires due to some long running RPC, the write to spanner
>>>> fails (because the deadline expired), and we don't get any log info.
>>>>
>>>> What's the best practice for dealing with this situation?
>>
>> --
>> 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/TUicHyvYNX0/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] Re: Extending deadline for logging

[Dave Cheney]

Thinking some more about the problem, I think your solution of reserving 
some of the deadline to handle the spanner log in the error case sounds 
like the best answer. However it does lead to questions like, if you 
reserve n seconds to log to spanner in the error path, and it takes longer 
than n, what happens to the error, is it dropped?

On Thursday, 16 August 2018 14:44:08 UTC+10, Dave Cheney wrote:
>
> What would happen if you write the error to spanner with a setting 
> context.Backgrond(), ie, no deadline? 
>
> On 16 August 2018 at 13:57, Robert Bartoszynski  wrote: 
> > Thanks. Perhaps an alternative would be for me to create a child context 
> > with a deadline of (context - x seconds) and pass that to OtherService, 
> with 
> > the expectation that there should be x seconds left over for the write 
> to 
> > spanner. 
> > 
> > On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote: 
> >> 
> >> 
> >> 
> >> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote: 
> >>> 
> >>> As an example: 
> >>> Client calls MyService with a deadline of 10 seconds. 
> >>> MyService calls OtherService as part of responding. However, the call 
> to 
> >>> OtherService times out due to the deadline in 10 seconds. 
> >>> MyService tries to log the error to Spanner; but it's still using that 
> >>> context deadline which expired. 
> >>> 
> >>> Is there a way to get a new context with an extended deadline? Are 
> there 
> >>> any issues with that approach? 
> >> 
> >> 
> >> Sure, just call context.WithDeadline(context.Background()) and use that 
> >> instead 
> >> 
> >>  The difficulty is you want the deadline of this new context to live 
> >> beyond its parent. Logically it feels like this new context is 
> subordinate 
> >> to the previous, but by design we've said that the new context is _not_ 
> >> subordinate -- the deadline does not apply to it. I think you need to 
> >> address this incongruousness before proceeding. 
> >> 
> >>> 
> >>> 
> >>> 
> >>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com 
> wrote: 
> >>>> 
> >>>> I'm working on a service that write some log info to spanner when 
> it's 
> >>>> done responding to a request. 
> >>>> However, the service uses the context's deadline to write to spanner, 
> so 
> >>>> if the deadline expires due to some long running RPC, the write to 
> spanner 
> >>>> fails (because the deadline expired), and we don't get any log info. 
> >>>> 
> >>>> What's the best practice for dealing with this situation? 
> >> 
> >> -- 
> >> 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/TUicHyvYNX0/unsubscribe. 
> >> To unsubscribe from this group and all its topics, send an email to 
> >> golang-nuts+unsubscr...@googlegroups.com. 
> >> For more options, visit https://groups.google.com/d/optout. 
>

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

[go-nuts] [Bug?] Error when running "go tool cover" on package name contains dot

[Dave Cheney]

Point of clarification, the package name doesn’t contain a dot, that is not 
permitted by the syntax of the package declaration. The name of the directory 
you placed the file in ends in .go and this is confusing the tool. 

If this is a regression from an earlier version of Go, please raise an issue. 

Thanks

Dave

-- 
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] [Bug?] Error when running "go tool cover" on package name contains dot

[Dave Cheney]

Thanks for confirming this is a regression.

On 20 August 2018 at 18:41, Shulhan  wrote:
> On Sun, 19 Aug 2018 16:13:00 -0700 (PDT)
> Dave Cheney  wrote:
>
>> Point of clarification, the package name doesn’t contain a dot, that
>> is not permitted by the syntax of the package declaration. The name
>> of the directory you placed the file in ends in .go and this is
>> confusing the tool.
>>
>
> Sorry, I write a misleading words in previous message.  I wrote
> "package name" where it should be "directory name".
>
>> If this is a regression from an earlier version of Go, please raise
>> an issue.
>>
>
> There is no problem when tested with Go v1.10.3.  I will report it
> later, thank you for checking this.

-- 
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] Does runtime.RaceDisable not work in non-std library ?

[Dave Cheney]

Hi,

Can you please do two things to help with this error report.

1. Please include the entire data race report -- we need this to match up 
the line with the source code you've provided in the gist
2. Please double check that you are not copying a your sync.Pool type by 
value, this can happen if you have a type declared on sync.Pool, not 
*sync.Pool, or it could happen if you do something like this

var x sync.Pool
y := x

Thanks

Dave

On Friday, 24 August 2018 13:46:10 UTC+10, nea...@gmail.com wrote:
>
> Hi lan,
>
> The sync.Pool has memory accesses in per-p private storage. Why it not 
> reports `DATA RACE`, but it reports when I copy those code outside stdlib?
> I'm confused about this, or there is something wrong in 
> https://gist.github.com/lrita/efa8c4ae555b4b7cceee29b4ed819652 
> Thanks.
>
> 在 2018年8月24日星期五 UTC+8上午4:36:06，Ian Lance Taylor写道：
>>
>> On Thu, Aug 23, 2018 at 12:43 AM,   wrote: 
>> > package main 
>> > 
>> > import "runtime" 
>> > 
>> > var a int 
>> > 
>> > func calc() { 
>> > for i := 0; i < 10; i++ { 
>> > go func() { 
>> > for { 
>> > runtime.RaceDisable() 
>> > a++ 
>> > runtime.RaceEnable() 
>> > } 
>> > }() 
>> > 
>> > } 
>> > } 
>> > 
>> > func main() { 
>> > calc() 
>> > } 
>> > 
>> > go run -race a.go 
>>
>> Thanks for the example.  As the docs for runtime.RaceDisable say, it 
>> only applies to synchronization events, like mutex locks.  It doesn't 
>> apply to memory accesses. 
>>
>> Ian 
>>
>>
>> > 在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道： 
>> >> 
>> >> On Wed, Aug 22, 2018 at 3:25 AM,   wrote: 
>> >> > 
>> >> > When I copy the sync.Pool's source code in a repo, and using 
>> >> > `//go:linkname` 
>> >> > link those runtime functions manually. 
>> >> > When I run `go test -race`, it reports `DATA RACE`. 
>> >> > But the sync.Pool with the same test case does not report  `DATA 
>> RACE`. 
>> >> > 
>> >> > Does runtime.RaceDisable not work in non-std library ? 
>> >> 
>> >> It should work.  I think you'll have to show us your code. 
>> >> 
>> >> 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.

[go-nuts] Re: Working or Not

[Dave Cheney]

Hi John

Unless the variables a1, a2, a3, b1, ... are defined in the same package as 
your showBoard function, ie

var a1, a2, a3 int

then Go will report that they are undefined. Unlike some other languages, 
Go does not implicitly define a variable on first occurance. All variables 
must be defined before they are used either at the package level, as 
parameters to a function, or local variables.

If you are still stuck please try to provide a complete program, 
play.golang.org is good for this, that shows the problem you are having and 
provides a way for someone else to replicate it.

Thanks

Dave

On Monday, 3 September 2018 13:42:12 UTC+10, John wrote:
>
> I am currently making a program with variables, but when I tried to run it 
> says that the variables are not defined. So below are may code for using 
> the variable:
>
> func showBoard()  {
>  fmt.Println("  1 2 3")
>  fmt.Println("a", a1, a2, a3)
>  fmt.Println("b", b1, b2, b3)
>  fmt.Println("c", c1, c2, c3)
> }
> PS: I used the newest go version and the atom compiler
>
>   
> 
>Sincerely
>   
> 
>  John
>
>

-- 
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] Performance regression of HTTP requests since Go 1.11

[Dave Cheney]

Can you post the output from httpstat?

-- 
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: Performance regression of HTTP requests since Go 1.11

[Dave Cheney]

This looks like an issue related to dns resolution in your environment with go 
1.11. 

I suggest building a reproducer using the net,Lookup* functions as the net/http 
package is not the problem. Once you have a reproduction case, please log an 
issue golang.org/issue/new 

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: Opening brace can't be placed on a separate line killing the language for me

[Dave Cheney]

I'm sorry you feel this way.

The reality is that the format of the language is not something that is 
going to change. I personally don't like that I cannot write one liner 
functions on one line because of gofmt's preference for reformatting the 
same function over three lines -- but, I put this aside because of the 
wider benefits of having a _single_ coding style that is enforced across 
all Go code (even if someone doesn't use it, I can pass their code though 
gofmt before reading it) which makes, to some degree, the syntax melt into 
the background.

I'd encourage you to persist with Go beyond the minor syntactic issues.

Dave

On Saturday, 8 September 2018 18:09:31 UTC+10, Mohamed yousry wrote:
>
> I don't know about you guys but for me format and readability is 
> everything so when I first heard about the language that Care about that ,I 
> was interested in it , after spending 2 days learning the language  I 
> decided that I have to put my new skill under the test to only find out I 
> can't tried to Google the error andd I was shocked when I found out that I 
> can't style my code the way I want. 
> Is it that hard for them to add some kind of exception for that kind of 
> problem. 
> I wish they really fix it or if there any fix please point it out . 
>  For me the language is Dead now it was a wasted time 
>

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

[go-nuts] Re: go 1.11 and XP

[Dave Cheney]

Go 1.11 doesn't support XP. We don't test on XP and won't fix bugs reported 
against XP systems any more. If it's working for you, great!, but if it 
breaks, you get to keep both pieces.

Dave

On Tuesday, 11 September 2018 05:05:23 UTC+10, wilk wrote:
>
> Hi, 
>
> Go 1.11 is not more compatible with Windows XP, but is it the compilator 
> or the executable or both ? 
>
> I just tried an app (build on linux) and doesn't see any failure... 
>
> -- 
> William 
>
>

-- 
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: Ambiguity in generic interfaces

[Dave Cheney]

I think D solved this quite well

https://dlang.org/spec/template.html

In your example this might become

type Foo(type T) interface {}
type Bar(type T) interface {

Foo!(T)

}


The exclamation point makes it clear this is the application of a T to the 
existing interface type Foo(type T).

On Friday, 14 September 2018 11:32:13 UTC+10, Patrick Smith wrote:
>
> (Apologies if this has already been brought up; I don't remember seeing 
> it.)
>
> While writing a bit of sample generics code, I ran into a nasty little 
> ambiguity:
>
> type Foo(type T) interface {}
> type Bar(type T) interface {
>
> Foo(T)
>
> }
>
>
> Does this embed the interface Foo(T) into Bar(T), or does it add to the 
> method set of Bar(T) a method named Foo taking a parameter of type T?
>

-- 
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] Periodic task when time.Ticker and time.Sleep are pretty expensive

[Dave Cheney]

I've confirmed this uses 14% on a random OS X machine. Please raise a bug, 
https://golang.org/issue/new

On Monday, 17 September 2018 14:29:44 UTC+10, Robert Engels wrote:
>
> For reference, similar code under Java consumes 2.5 % CPU.
>
> I tested the Go code under OSX, and it is roughly 10%, which seems to be 
> very high. Might be because the “context switching” is performed/attributed 
> to the process (since it is internal), where for other systems it is the 
> system call only, and so most of the cost is attributed to system/kernel 
> activity.
>
>
>
> On Sep 16, 2018, at 8:47 AM, Lei Ni > 
> wrote:
>
> import (
>   "time"
> )
>
> func main() {
>   ticker := time.NewTicker(time.Millisecond)
>   defer ticker.Stop()
>   for range ticker.C {
>   }
> }
>
>
>

-- 
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: Run time error

[Dave Cheney]

Assuming you are using the master branch of go-ifps-api, this request is 
failing because RequestBuilder.shell is nil. This could happen for a 
variety of reasons, perhaps the lack of error handling in NewLocalShell. 

I recommend you handle this with the ipfs developers on 
https://github.com/ipfs/go-ipfs-api/issues/125


On Tuesday, 18 September 2018 01:42:26 UTC+10, akshita babel wrote:
>
> When I am running a program which is for a web response I am getting a run 
> time error as follows:
> http: panic serving 127.0.0.1:43802: runtime error: invalid memory 
> address or nil pointer dereference
> goroutine 6 [running]:
> net/http.(*conn).serve.func1(0xc4200a4a00)
> /usr/lib/go-1.10/src/net/http/server.go:1726 +0x11b
> panic(0x9b5360, 0xd99230)
> /usr/lib/go-1.10/src/runtime/panic.go:502 +0x24a
> github.com/ipfs/go-ipfs-api.(*RequestBuilder).Send(0xc4201740a0, 
> 0xb95c60, 0xc420022100, 0x0, 0x0, 0x0)
> The code of main file is as follows:
> func main() {
>
> router := httprouter.New()
> router.RedirectTrailingSlash = true
> c := cors.New(cors.Options{
>   AllowedOrigins:   []string{"*"},
>   AllowedMethods:   []string{"GET", "POST", "OPTIONS", "Authorization"},
>   AllowedHeaders:   []string{"*"},
>   AllowCredentials: true,
> })
> router.GET("/create", StoreAndGetHash)
> router.GET("/read/:hashvalue", GetFile)
> router.GET("/appdata/:appID", ReadPeer)
> router.GET("/update", UpdateAndGetHash)
> router.GET("/createdir", GetDir)
> router.GET("/newkey", GetNewKey)
>
> log.Fatal(http.ListenAndServe(":3000", c.Handler(router)))
>
> }
>
> I am working on ubuntu
>

-- 
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: Tour Of go Page 8 in Basics does not work.

[Dave Cheney]

It looks like the playground has cached this error. Please raise an issue, 
https://golang.org/issue/new and someone with admin powers will delete the 
faulty entry.

On Tuesday, 18 September 2018 17:03:00 UTC+10, Reinhard Luediger wrote:
>
> Hey List,
>
> is this the right place to get the tour of go fixed? The example on the 
> following page https://tour.golang.org/basics/8 terminates unexpected 
> with error  process took to long.
>
> kind regards
>
>
> Reinhard Lüdiger
>

-- 
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] Interaction of signals with defer

[Dave Cheney]

pkg /profile will do the paperwork for you so ^C works when profiling. 

-- 
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] Interaction of signals with defer

[Dave Cheney]

profile.Start() installs a ^C handler to try to make sure profiles are properly 
flushed to disk before your process goes to the bit bucket in the sky. 

> On 19 Sep 2018, at 12:23, andrey mirtchovski  wrote:
> 
> you're talking about https://github.com/pkg/profile, presumably. while
> i did find that fairly quickly and it appears to be very useful, it
> wasn't immediately obvious that it would solve my particular issue.
> unfortunately we're also averse to importing third-party packages
> without additional vetting. i ended up using the http/pprof package
> from the stdlib which gave me what i wanted.
>> On Tue, Sep 18, 2018 at 7:55 PM Dave Cheney  wrote:
>> 
>> pkg /profile will do the paperwork for you so ^C works when profiling.
>> 
>> --
>> 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: I am not in favor of generics.

[Dave Cheney]

Thank you to everyone who has contributed to this thread. 

It is time for everyone to take a break for 48 hours. After this time if you 
feel strongly that there is a point which you must continue to debate please do 
so, but be mindful that many words have already been spent in this thread and 
the points of view expressed are unlikely to change. 

Thank you

Dave

-- 
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: Local variable escapes to heap

[Dave Cheney]

If you pass more -m's to the compiler it will explain why

Daves-MacBook-Pro(~/src) % go build -gcflags=-m=2 buffer.go
# command-line-arguments
./buffer.go:12:6: cannot inline main: function too complex: cost 108 
exceeds budget 80
./buffer.go:15:21: buffer escapes to heap
./buffer.go:15:21:  from Builder literal (struct literal element) at 
./buffer.go:15:14
./buffer.go:15:21:  from b (assigned) at ./buffer.go:15:4
./buffer.go:15:21:  from b.meta.Index() (receiver in indirect call) at 
./buffer.go:18:15
./buffer.go:13:6: moved to heap: buffer
:1: leaking param: .this
:1:  from .this.Index() (receiver in indirect call) at 
:1

I recommend raising a bug https://golang.org/issue/new if you feel the 
compiler could prove that main.buffer did not escape.

On Thursday, 20 September 2018 12:39:33 UTC+10, Alex Bahdanau wrote:
>
> Hi all,
>
> I've read a lot about escape analysis in golang, but still couldn't find 
> an answer to this question
> here is the sample :
>
> package main
>
> type IMeta interface {
> Index() int
> }
>
> type Builder struct {
> buf  []byte
> meta IMeta
> }
>
> func main() {
> var buffer [512]byte
>
> b := Builder{buffer[:0], nil}
>
> if b.meta != nil {
> b.meta.Index()
> }
> }
>
> escape analyzer says:
> .\main.go:15:21: buffer escapes to heap
> .\main.go:13:6: moved to heap: buffer
> :1:0: leaking param: .this
>
> Could anyone please clarify why local buffer escapes here?
>
> Thx in advance
>
>

-- 
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: Using modules with go test ./...

[Dave Cheney]

I think because GOPATH is not set it is defaulting to $HOME/go (see Go 1.9 
release notes, from memory). Try moving your code to another folder.



On Friday, 21 September 2018 05:21:32 UTC+10, John wrote:
>
> Just started playing with modules recently. Having an issue I don't 
> understand, wondering if anyone has seen it, the few references to the 
> error did not provide anything I saw relevant for what I'm doing.
>
> given a directory structure such as:
>
> /go/
>   src/
>   pkg/
>   bin/
>
> GOPATH NOT SET
> GO111MODULE = on
>
> If the working directory is:
> /go/src/
>
> go test ./...
>
> *Results in:*
> go: cannot determine module path for source directory /home/jdoak/go/src 
> (outside GOPATH, no import comments)
>
> This also occurs if I do:
>
> go test subdir/subdir/packagedir/...
>
> But it will work if I do:
>
> working directory: /go/src/subdir/subdir/packagedir/
>
> go test ./...
>
> I'm sure I'm doing something wrong.  If someone could enlighten me.
>
>

-- 
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: Using modules with go test ./...

[Dave Cheney]

Sorry, I probably wasn’t clear or didn’t understand that you were asking. I saw 
that you said GOPATH is not set, it because your code is inside $HOME/go, 
because of the rules of the default gopath introduced in 1.8, gopath IS 
actually set. 

To be extra sure, when I’m playing with go modules I use a different directory 
for my experiments, ~/devel in my case, to avoid conflicts with explicit or 
implicit gopaths

-- 
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] Adding packages for the lang

[Dave Cheney]

Additions to the language are handled via a written proposal process.

https://github.com/golang/proposal/blob/master/README.md

-- 
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] The If Statement: Switches are better except for a single condition (change my mind)

[Dave Cheney]

On Tuesday, 25 September 2018 10:22:52 UTC+10, Louki Sumirniy wrote:
>
> Using named return values and this construction you can drop all those 
> returns in each case block to outside the block. You only need to spend an 
> extra line if you have to break out of it by return or break.
>

Go is not a language that trades clarity for brevity. 

-- 
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] idiomatic code to find, if executable exists in golang

[Dave Cheney]

Are you able to modify the original question. Why do you need to know if a 
binary exists? Presumably so you can execute it. If so then you can modify the 
original request and make the problem more tractable. 

-- 
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: idiomatic code to find, if executable exists in golang

[Dave Cheney]

My suggestion is, rather than seeing if an executable exists, then executing 
it. Just execute it and if there is an error just pass it back to the caller. 
The difference between I tried to run the program but it wasn’t found and I 
tried to run the program but it failed for some reason shouldn’t matter. 

-- 
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: Canonical module arrangement in a multi-language project.

[Dave Cheney]

With the modules support added to Go 1.11 this should be straight forward.

Create a subdirectory for your go code inside your working copy; change 
into that and run 

go mod init example.com/your/repo

Where example.com/your/repo is a placeholder for the _prefix_ you want to 
apply to all of the packages inside your module, replace it with whatever 
makes sense for your company and project.

>From then on, your Go code can be built by changing into that subdirectory 
and running go build.

Dave

On Friday, 28 September 2018 09:48:54 UTC+10, Ian Bruene wrote:
>
>
> I am working on setting up NTPsec's build system to properly handle Go 
> code, and can only find limited information of the preferred way of 
> structuring the directory tree.
>
> Forcing the entire project into GOPATH would be sloppy and a giant kluge 
> all around.
>
> Placing the go code in a folder with no special structure (as we currently 
> do with Python), and then using relative module paths appears to work in 
> testing. However from what I gather relative module paths are a deeply 
> unkosher feature that should not be depended on.
>
> The only other way I see is simply to replicate a GOPATH directory 
> structure within the project and have the build tools define a custom 
> GOPATH. This forces a somewhat clunky directory structure on the project 
> with an otherwise unneeded src/ directory. A possible workaround would be 
> to structure the code as with Python, then have the build system copy the 
> files into a src/ directory under build/ and run with that GOPATH.
>
>

-- 
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 this implementation of weak pointers safe?

[Dave Cheney]

Please don’t take os.File as justification, it’s one of the few uses of a 
finaliser in the std lib. If it were being written today I would argue that 
instead of silently closing the file, it should panic if the resource falls out 
of scope unclosed. 

As always, remember that finalisers are not guaranteed to run as they are tied 
to the gc cycle. In a well tuned application a finaliser can easily be delayed 
until the resource they are meant to mediate has been exhausted by 
overconsumption. 

Dave

-- 
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: [golang-dev] does net.Conn.SetDeadLine makes syscall ?

[Dave Cheney]

In this case it looks like to be correct you must set the deadline
before reading from the network, and given reading from the network
can block, the cost of setting the deadline is small.

On Sat, 6 Apr 2019 at 21:47, Santhosh T  wrote:
>
> Hi Dave,
>
> my mistake, bufr is backed by net.Conn
>
> bufr := bufio.newReader(netConn)
> for numEntries >0 {
> numEntries--
> netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> entry.decode(bufr)
> process(entry)
> }
>
> thanks
> Santhosh
>
> On Sat, Apr 6, 2019 at 4:09 PM Dave Cheney  wrote:
>>
>> Thanks for the explanation. Two things
>>
>> 1. As this is a question about how to write a Go program, you should
>> move this thread to golang-nuts, golang-dev is only for the
>> development of Go.
>> 2. From the sample code you provided, there is no call to
>> netConn.Read, so setting the deadline is unnecessary. Please move the
>> discussion to golang-nuts and consider posting a larger piece of
>> sample code that shows the interaction with the network.
>>
>> On Sat, 6 Apr 2019 at 21:27, Santhosh T  wrote:
>> >
>> > Hi Dave,
>> >
>> > I am implementing raft protocol, where leader sends bunch of entries over 
>> > net.Conn to follower.
>> >
>> > leader can send large number of entries in single net.Conn.write.
>> > if follower does not hear from leader within configured heartbeatTimeout, 
>> > it has to start election.
>> >
>> > currently follower implementation is something like this:
>> >
>> > for numEntries >0 {
>> > numEntries--
>> > netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
>> > entry.decode(bufr)
>> > process(entry)
>> > }
>> >
>> > if numEntries is say 1, i would be spending significant time in 
>> > makeing syscalls for setReaddeadline
>> > btw, i have not done any benchmark yet. I asked the question our of 
>> > curiosity.
>> >
>> > What i was planning to do to optimize it is:
>> >  as i am reading entry from bufr, in most cases the entry might be 
>> > already in the buffer. in such case
>> > i can avoid setting readDeadline. so set deadline, only when bufr calls 
>> > read on underlaying reader.
>> >
>> > hope i am clear...
>> >
>> > thanks
>> > Santhosh
>> >
>> > On Sat, Apr 6, 2019 at 2:53 PM Dave Cheney  wrote:
>> >>
>> >> Hi Santhosh,
>> >>
>> >> Calling SetDeadline does not _directly_ trigger a syscall, but it does
>> >> have several other observable side effects. What is the problem you
>> >> are facing that lead you to ask this question?
>> >>
>> >> Thanks
>> >>
>> >> Dave
>> >>
>> >> On Sat, 6 Apr 2019 at 20:20, Santhosh Kumar T  
>> >> wrote:
>> >> >
>> >> > does net.Conn.SetDeadLine makes syscall ?
>> >> >
>> >> > thanks
>> >> > santhosh
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google 
>> >> > Groups "golang-dev" group.
>> >> > To unsubscribe from this group and stop receiving emails from it, send 
>> >> > an email to golang-dev+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: No Allman-Style, No go!

[Dave Cheney]

Thank you for keeping the dream of this thread alive.

-- 
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: golang-codereview - purpose

[Dave Cheney]

I read it. It lets me know which changes have been proposed.

On Sunday, 23 July 2017 09:42:57 UTC+10, Carlos wrote:
>
> Hi,
>
>
> I have subscribed golang-codereview list for a while. Even filtering out 
> for keywords, it is still a lot of emails. I'd assume that such list would 
> have a good reason to exist - but I cannot really figure out what this 
> reason is.
>
> Does anyone here really read it? Or just a subset of it? if so, how do you 
> manage it?
>
>
> Thanks,
> Ulderico
>

-- 
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: golang-codereview - purpose

[Dave Cheney]

yup

On Sun, Jul 23, 2017 at 11:59 AM, Ulderico Cirello
 wrote:
> Just confirming, you read all of it?
>
> Il giorno sab 22 lug 2017 alle ore 18:17 Dave Cheney  ha
> scritto:
>>
>> I read it. It lets me know which changes have been proposed.
>>
>>
>> On Sunday, 23 July 2017 09:42:57 UTC+10, Carlos wrote:
>>>
>>> Hi,
>>>
>>>
>>> I have subscribed golang-codereview list for a while. Even filtering out
>>> for keywords, it is still a lot of emails. I'd assume that such list would
>>> have a good reason to exist - but I cannot really figure out what this
>>> reason is.
>>>
>>> Does anyone here really read it? Or just a subset of it? if so, how do
>>> you manage it?
>>>
>>>
>>> Thanks,
>>> Ulderico
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: How to determine when to actually use goroutines?

[Dave Cheney]

This presentation, or more accurately, the summary at the end, may be of 
interest to you.

https://dave.cheney.net/paste/concurrency-made-easy.pdf

A recording of this presentation at GopherCon Signapore is also available 
by searching for those keywords.

On Tuesday, 25 July 2017 01:34:30 UTC+10, Glen Huang wrote:
>
> Hi,
>
> I'm still pretty new to go. Hope this question isn't too stupid.
>
> I'm writing a restful API server, and in order to send a response, I need 
> to query a db to get its content type and then send the actually file that 
> lives on the file system. Now the question is, should I put db.QueryRow and 
> os.Open each in a goroutine to make them concurrent?
>
> And a more general question is, when using APIs from the stdlib or 
> 3rd-party packages, how do I determine whether to wrap them in goroutines 
> when more than one of them need to happen sequentially and the order 
> actually doesn't matter? Should I manually time the API executions to make 
> the call? Should I writing things sequentially by default and only when 
> hitting performance problems do I profile the program and wrap calls in 
> goroutine?
>
> How do you decide when to use goroutines?
>

-- 
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: What is pprof overhead like when gathering a profile?

[Dave Cheney]

Here's an entirely unscientific method to determine the overhead of 
profiling. The Go distribution contains a set of basic benchmarks, one of 
which is a loopback based http client server benchmark. Running the 
benchmark with and without profiling gives a rough ballpark for the 
overhead of profiling.

lucky(~/go/test/bench/go1) % go test -run=XXX -bench=HTTPClientServer
goos: linux
goarch: amd64
BenchmarkHTTPClientServer-42 84296 ns/op
PASS
ok  _/home/dfc/go/test/bench/go14.274s
lucky(~/go/test/bench/go1) % go test -run=XXX -bench=HTTPClientServer 
-cpuprofile=/tmp/c.p
goos: linux
goarch: amd64
BenchmarkHTTPClientServer-42 85316 ns/op
PASS
ok  _/home/dfc/go/test/bench/go14.402s

You could use this to experiment with the other kinds of profiles; memory, 
block, trace, etc.

If you wanted to go a step further you could adding profiling to your own 
project with my github.com/pkg/profile package then compare the results of 
a http load test with and without profiling enabled.

Thanks

Dave

On Tuesday, 25 July 2017 10:44:10 UTC+10, nat...@honeycomb.io wrote:
>
> Hello,
>
> I am curious what the performance impact of running pprof to collect 
> information about CPU or memory usage is. Is it like strace where there 
> could be a massive slowdown (up to 100x) or is it lower overhead, i.e., 
> safe to use in production? The article here - 
> http://artem.krylysov.com/blog/2017/03/13/profiling-and-optimizing-go-web-applications/
>  
> - suggests that "one of the biggest pprof advantages is that it has low 
> overhead and can be used in a production environment on a live traffic 
> without any noticeable performance penalties". Is that accurate?
>
> Thanks!
>
> Nathan
>

-- 
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: What is pprof overhead like when gathering a profile?

[Dave Cheney]

Another option is to profile a % of requests. In the past I've done that by 
enabling profiling on a set % of application servers then extrapolating 
from there.

On Tuesday, 25 July 2017 10:55:42 UTC+10, Jaana Burcu Dogan wrote:
>
> It would be very speculative to provide reference numbers without actually 
> seeing the specific program. You can benchmark the latency/throughput with 
> the CPU profiler on to see a realistic estimate. FWIW, memory profiling, 
> goroutine, thread create profiles are always on. At Google, we continuously 
> profile Go production services and it is safe to do so.
>
>
> On Monday, July 24, 2017 at 5:44:10 PM UTC-7, nat...@honeycomb.io wrote:
>>
>> Hello,
>>
>> I am curious what the performance impact of running pprof to collect 
>> information about CPU or memory usage is. Is it like strace where there 
>> could be a massive slowdown (up to 100x) or is it lower overhead, i.e., 
>> safe to use in production? The article here - 
>> http://artem.krylysov.com/blog/2017/03/13/profiling-and-optimizing-go-web-applications/
>>  
>> - suggests that "one of the biggest pprof advantages is that it has low 
>> overhead and can be used in a production environment on a live traffic 
>> without any noticeable performance penalties". Is that accurate?
>>
>> Thanks!
>>
>> Nathan
>>
>

-- 
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: Go import tree

[Dave Cheney]

This feature is enabled on any package you view through godoc.org; just 
look at the bottom of the page.

On Monday, 31 July 2017 10:15:43 UTC+10, Steve Roth wrote:
>
> https://github.com/davecheney/prdeps is another.
> Steve
>
> On Saturday, July 29, 2017 at 9:55:05 PM UTC-7, Tong Sun wrote:
>>
>> Is there any tools out there that can show import tree for Go projects? 
>> I.e., the dependency graph that shows who imports what packages. 
>>
>> During `go build -v` I saw one (3rd party) package that shouldn't be 
>> included, and am wondering who is introducing that dependency. 
>> How can I find out? Thx. 
>>
>>
>>

-- 
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: pet peeve: it's Go not golang

[Dave Cheney]

>
> Golang helps much, when searching for Go related programming issues all 
> over the internet 
>
>
Skip's point, which I heartily support, is here, on this forum, there is 
little ambiguity what people refer to when they talk about the programming 
language called 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.

[go-nuts] Re: Proper way to construct|format this code...

[Dave Cheney]

https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88

-- 
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: Socket Priority affect Read Deadline?

[Dave Cheney]

http://godoc.org/net#UDPConn.File

"The returned os.File's file descriptor is different from the connection's. 
Attempting to change properties of the original using this duplicate may or 
may not have the desired effect."

On Wednesday, 2 August 2017 23:34:16 UTC+10, jlu...@gmail.com wrote:
>
> Hi guys,
>
> I wrapped some code to do listen UDP port and set priority,  like this
>
> func ListenUDP(t string, laddr *net.UDPAddr, priority int) (*net.UDPConn, 
> error) {
> conn, err := net.ListenUDP(t, laddr)
> if err != nil {
> return nil, err
> }
>
> if priority < 0 {
> return conn, nil
> }
>
> file, err := conn.File()
> if err != nil {
> conn.Close()
> return nil, fmt.Errorf("error in getting file for the connection")
> }
> defer file.Close()
>
> err = syscall.SetsockoptInt(int(file.Fd()), syscall.SOL_SOCKET, 
> syscall.SO_PRIORITY, priority)
> if err != nil {
> return nil, fmt.Errorf("error in setting priority option on 
> socket: %s", err)
> }
>
> return conn, nil
> }
>
> And, read data from that port with timeout
>
> conn.SetReadDeadline(time.Now().Add(time.Second * 5))
> n, addr, err = conn.ReadFromUDP(buf)
>
> But, i found the deadline not work...
>
> Any good suggestions?
>

-- 
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] lock for assigning to different elements of an array

[Dave Cheney]

No, but anything reading from that array which is not the original writer will 
have to coordinate via a lock or channel to ensure a proper happens before 
relationship exists. 

-- 
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] lock for assigning to different elements of an array

[Dave Cheney]

I'm not really sure what you are asking. I think your second paragraph got 
eaten by autocorrect at the critical point. Could try maybe asking your 
question in a different way?

-- 
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] lock for assigning to different elements of an array

[Dave Cheney]

IMO you need a lock whenever you are sharing a value between goroutines by
storing it in memory.

On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:

> I think I am mostly after a mental pattern to easily recognise when
> synchronizations are needed.
>
> I am decently good at this but I tend to be very conservative and use
> locks and atomics perhaps when they are not needed.
> But here we have several goroutines all taking part in the initialisation
> itself concurrently writing to the same array. How can this be safe in
> light of https://golang.org/ref/mem#tmp_10 . I get that your comment
> about "happens before" comes in here if there were any readers but
> eventually there will be readers or we would never need to do this. If the
> main after some time wants to access these values is it enough to make sure
> the goroutines are done perhaps using a WaitGroup or do we have to use some
> other synchronisation to ensure the visibility of the data in the array?
>
>  https://play.golang.org/p/8BfrPhyIEb
>
> Or is it needed to do something like this:
>
> https://play.golang.org/p/9QgTP5Dqc7
>
> I mean aside from the poor form of sleeping like this, the idea is to
> simulate usage "at some point later in time".
>
> It gets hypothetical pretty quick and usually when this happens I make
> sure to create a new array/slice/whatever and then atomically swap it
> before some other goroutine uses it but I generally avoid indexing
> assignment from go routines like this even though it seems to be ok.
>
> Does this hold for slices as well as for arrays? What about assignments to
> fields in structs? Can several goroutines safely write to different fields
> in the same struct assuming they are word sized? Does this hold for all
> architectures?
>
> I am sorry if I am still a bit unclear but I find it hard to ask properly
> when I am a bit unsure of the topic. :D
>
>
>
> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>
>> I'm not really sure what you are asking. I think your second paragraph
>> got eaten by autocorrect at the critical point. Could try maybe asking your
>> question in a different way?
>
>
>>
>> --
>> 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] lock for assigning to different elements of an array

[Dave Cheney]

Your first program has a data race, well it has two races, the first is a
data race between the goroutines writing to the slice and the println which
will read the contents of the slice. That is, if those writing goroutines
get a chance to run before main exits.

The second program doesn't have a data race as the waitgroup.done / wait
creates a happens before relationship between reader and writer.

On Thu, 3 Aug 2017, 17:33 Henrik Johansson  wrote:

> But isn't this what is happening in the example? Or is write-only not
> sharing?
>
> On Thu, 3 Aug 2017, 09:23 Dave Cheney,  wrote:
>
>> IMO you need a lock whenever you are sharing a value between goroutines
>> by storing it in memory.
>>
>> On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:
>>
>>> I think I am mostly after a mental pattern to easily recognise when
>>> synchronizations are needed.
>>>
>>> I am decently good at this but I tend to be very conservative and use
>>> locks and atomics perhaps when they are not needed.
>>> But here we have several goroutines all taking part in the
>>> initialisation itself concurrently writing to the same array. How can this
>>> be safe in light of https://golang.org/ref/mem#tmp_10 . I get that your
>>> comment about "happens before" comes in here if there were any readers but
>>> eventually there will be readers or we would never need to do this. If the
>>> main after some time wants to access these values is it enough to make sure
>>> the goroutines are done perhaps using a WaitGroup or do we have to use some
>>> other synchronisation to ensure the visibility of the data in the array?
>>>
>>>  https://play.golang.org/p/8BfrPhyIEb
>>>
>>> Or is it needed to do something like this:
>>>
>>> https://play.golang.org/p/9QgTP5Dqc7
>>>
>>> I mean aside from the poor form of sleeping like this, the idea is to
>>> simulate usage "at some point later in time".
>>>
>>> It gets hypothetical pretty quick and usually when this happens I make
>>> sure to create a new array/slice/whatever and then atomically swap it
>>> before some other goroutine uses it but I generally avoid indexing
>>> assignment from go routines like this even though it seems to be ok.
>>>
>>> Does this hold for slices as well as for arrays? What about assignments
>>> to fields in structs? Can several goroutines safely write to different
>>> fields in the same struct assuming they are word sized? Does this hold for
>>> all architectures?
>>>
>>> I am sorry if I am still a bit unclear but I find it hard to ask
>>> properly when I am a bit unsure of the topic. :D
>>>
>>>
>>>
>>> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>>>
>>>> I'm not really sure what you are asking. I think your second paragraph
>>>> got eaten by autocorrect at the critical point. Could try maybe asking your
>>>> question in a different way?
>>>
>>>
>>>>
>>>> --
>>>> 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] lock for assigning to different elements of an array

[Dave Cheney]

On Thu, 3 Aug 2017, 17:39 Dave Cheney  wrote:

> Your first program has a data race, well it has two races, the first is a
> data race between the goroutines writing to the slice and the println which
> will read the contents of the slice. That is, if those writing goroutines
> get a chance to run before main exits.
>
> The second program doesn't have a data race as the waitgroup.done / wait
> creates a happens before relationship between reader and writer.
>
> On Thu, 3 Aug 2017, 17:33 Henrik Johansson  wrote:
>
>> But isn't this what is happening in the example? Or is write-only not
>> sharing?
>>
>> On Thu, 3 Aug 2017, 09:23 Dave Cheney,  wrote:
>>
>>> IMO you need a lock whenever you are sharing a value between goroutines
>>> by storing it in memory.
>>>
>>> On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:
>>>
>>>> I think I am mostly after a mental pattern to easily recognise when
>>>> synchronizations are needed.
>>>>
>>>> I am decently good at this but I tend to be very conservative and use
>>>> locks and atomics perhaps when they are not needed.
>>>> But here we have several goroutines all taking part in the
>>>> initialisation itself concurrently writing to the same array. How can this
>>>> be safe in light of https://golang.org/ref/mem#tmp_10 . I get that
>>>> your comment about "happens before" comes in here if there were any readers
>>>> but eventually there will be readers or we would never need to do this. If
>>>> the main after some time wants to access these values is it enough to make
>>>> sure the goroutines are done perhaps using a WaitGroup or do we have to use
>>>> some other synchronisation to ensure the visibility of the data in the
>>>> array?
>>>>
>>>>  https://play.golang.org/p/8BfrPhyIEb
>>>>
>>>> Or is it needed to do something like this:
>>>>
>>>> https://play.golang.org/p/9QgTP5Dqc7
>>>>
>>>> I mean aside from the poor form of sleeping like this, the idea is to
>>>> simulate usage "at some point later in time".
>>>>
>>>> It gets hypothetical pretty quick and usually when this happens I make
>>>> sure to create a new array/slice/whatever and then atomically swap it
>>>> before some other goroutine uses it but I generally avoid indexing
>>>> assignment from go routines like this even though it seems to be ok.
>>>>
>>>> Does this hold for slices as well as for arrays?
>>>>
>>>
Yes, it is safe for multiple goroutines to write to different array
elements, the same is true for slices as they are backed by an array

What about assignments to fields in structs?
>>>>
>>>
Yes.

Can several goroutines safely write to different fields in the same struct
>>>> assuming they are word sized?
>>>>
>>>
Yes, although they should also be naturally aligned.

Does this hold for all architectures?
>>>>
>>>
Some architectures have issues with atomic writes to values smaller than a
word. Look for xor8 in the runtime source.

Writing to adjacent memory locations will cause false sharing between CPU
caches. This is a performance, not a correctness issue.


>>>> I am sorry if I am still a bit unclear but I find it hard to ask
>>>> properly when I am a bit unsure of the topic. :D
>>>>
>>>>
>>>>
>>>> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>>>>
>>>>> I'm not really sure what you are asking. I think your second paragraph
>>>>> got eaten by autocorrect at the critical point. Could try maybe asking 
>>>>> your
>>>>> question in a different way?
>>>>
>>>>
>>>>>
>>>>> --
>>>>> 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: Error when using go tool trace

[Dave Cheney]

On Friday, 4 August 2017 15:46:39 UTC+10, Evan Leis wrote:
>
> I ran into this same problem, and found this post!
> It looks like you're making the same simple mistake I was:
>
> # erroneous:
> defer f.Close()
> defer trace.Stop()
>

Defers run in LIFO order. This sample will call trace.Stop, then f.Close(). 

>
> You must stop the trace *before* closing the output file.
>
> # corrected:
> defer func() {
>   trace.Stop()
>   panic(f.Close()) # Be sure to handle file-closing errors. They're 
> important!!
> }
>

This sample will panic the program every time 
 

>
> On Tuesday, October 11, 2016 at 8:21:17 AM UTC-6, xavier zebier wrote:
>>
>> Hello,
>> I m trying to use the go tool trace. My code is 
>>
>>
>> package main
>>
>> import (
>> "flag"
>> "fmt"
>> "math"
>> "net/http"
>> "os"
>> "runtime"
>> "runtime/trace"
>> "time"
>> )
>>
>> func indexHandler(w http.ResponseWriter, r *http.Request) {
>> primesInRangeParallel(10, 64)
>> fmt.Fprintf(w, "hello world, I'm running on %s with an %s CPU ", 
>> runtime.GOOS, runtime.GOARCH)
>>
>> }
>>
>> func main() {
>> flag.Parse()
>> f, errs := os.Create(time.Now().Format("2006-01-02T150405.out"))
>> if errs != nil {
>> panic(errs)
>> }
>>
>> if err := trace.Start(f); err != nil {
>> panic(err)
>> }
>>
>> defer f.Close()
>> defer trace.Stop()
>> http.HandleFunc("/", indexHandler)
>>
>> http.ListenAndServe(":8080", nil)
>> }
>>
>> // We will use this struct to communicate results via a channel
>> type PrimeResult struct {
>> number int64 // A number
>> prime  bool  // Is prime or not
>> }
>>
>> /**
>>  * A function to return a prime calculation over a channel. This way
>>  * we don't need to have 2 versions of isPrime function, one for
>>  * sequential calculations and another for paralel
>>  */
>>
>> func isPrimeAsync(number int64, channel chan PrimeResult) {
>>
>> result := new(PrimeResult)
>> result.number = number
>> result.prime = isPrime(number)
>> channel <- *result
>> }
>>
>> /**
>>  * Accepts a range of integers [min, max] and a channel and it executes
>>  * in PARALEL the processes that check if a number is prime or not.
>>  *
>>  * This function does nothing with the result. In another point, somebody
>>  * will have to read the channel and process the results
>>  */
>> func firePrimeCalculations(min int64, max int64, channel chan 
>> PrimeResult) {
>> var i int64
>> for i = min; i <= max; i++ {
>> go isPrimeAsync(i, channel)
>> }
>> }
>>
>> /**
>>  * Accepts a range of integers [min, max] and
>>  * returns an array with all the prime numbers in this range.
>>  *
>>  * Execution is done in paralel. First it fires all the
>>  * processes that check for a prime number. These processes
>>  * will write the result in a channel.
>>  *
>>  * We will receive the results over this channel creating the
>>  * list of prime numbers and returning it
>>  *
>>  */
>>
>> func primesInRangeParallel(min int64, max int64) []int64 {
>> var primeNumbers []int64
>> var res PrimeResult
>> var prev int64
>>
>> channel := make(chan PrimeResult)
>> defer close(channel)
>>
>> go firePrimeCalculations(min, max, channel)
>>
>> prev = 0
>> for i := min; i <= max; i++ {
>> res = <-channel
>> if res.prime {
>> primeNumbers = append(primeNumbers, res.number)
>>
>> done := 100 * (i - min) / (max - min)
>> if prev != done {
>> fmt.Printf("%d %% done.\n", done)
>> prev = done
>> }
>> }
>> }
>> return primeNumbers
>> }
>> func isPrime(candidate int64) bool {
>> var i, limit int64
>>
>> if candidate == 2 {
>> return true
>> }
>>
>> if math.Mod(float64(candidate), 2) == 0 {
>> return false
>> }
>>
>> limit = int64(math.Ceil(math.Sqrt(float64(candidate
>> for i = 3; i <= limit; i += 2 { //Only odd numbers
>> if math.Mod(float64(candidate), float64(i)) == 0 {
>> return false
>> }
>> }
>> return true
>> }
>>
>> The prime number calculation is basically there to get some calculation.
>>
>> My go env command gives  : 
>>
>> C:\repo\gonew\src\github.com\tixu\trace>go env
>> set GOARCH=amd64
>> set GOBIN=
>> set GOEXE=.exe
>> set GOHOSTARCH=amd64
>> set GOHOSTOS=windows
>> set GOOS=windows
>> set GOPATH=c:\repo\gonew
>> set GORACE=
>> set GOROOT=C:\Go
>> set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
>> set CC=gcc
>> set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
>> set CXX=g++
>> set CGO_ENABLED=1
>>
>>
>>
>> And I get the following error :
>>
>> C:\repo\gonew\src\github.com\tixu\trace>go tool trace Trace 
>> 2016-10-11T153554.out
>> 2016/10/11 15:36:45 Parsing trace...
>> failed to parse trace: no EvFrequency event 
>>
>> Can you help me .?
>>
>> Thanks in advance,
>>
>> Xavier
>>
>

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