Re: [go-nuts] Re: go get: You are not currently on a branch

On Thu, Oct 13, 2016 at 3:59 AM Tong Sun wrote: > You can blame git, but I think "go get" can do better to avoid the problem in the first place. 'go get' just executes `git clone` or `git pull`. What would you suggest 'go get' can do to "do better"? -- -j -- You

Re: [go-nuts] infinite loop makes program stuck

On Wed, Oct 12, 2016 at 1:33 AM Minglangjun Li wrote: > On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis > wrote: > > If you have multiple CPUs (and the Go memory model assumes that you > always can) they won't even write updated values from their

[go-nuts] Re: Survey - do you use Go in the cloud?

Hi Ondrej, thanks for the feedback! While the intent of this particular survey was to understand what kind of workloads go customers were running on various cloud providers, we're also taking a close look at previous surveys that have looked at vendoring and packaging preferences, as well as

Re: [go-nuts] Re: go get: You are not currently on a branch

Hi Oir, The main problem seems to be related to go get believe me or not. I manage to get this right after I deleted $GOPATH/pkg/* and $GOPATH/src/golang.org Thanks On Wednesday, October 12, 2016 at 3:51:07 PM UTC+2, ohir wrote: > > Dnia 2016-10-12, o godz. 02:37:16 > Thomas Modeneis

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

I see that Ian has already answered your question. > But the crucial point is that this is an implicit and unspecified (as in > "not in the spec") property of those operations. Although not very verbose, I believe that the Go Memory Model (as I quoted earlier) is the guarantee. And I

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Thanks for clarifying that Ian! On Wed, Oct 12, 2016, 19:21 Ian Lance Taylor wrote: > On Wed, Oct 12, 2016 at 9:39 AM, Konstantin Khomoutov > wrote: > > On Wed, 12 Oct 2016 07:36:15 -0500 > > John Souvestre wrote: > > > >>

Re: [go-nuts] Function pointer vs interface for callback?

Thanks for the tips. On Wed, Oct 12, 2016 at 2:11 PM Jesse McNelis wrote: > On Wed, Oct 12, 2016 at 11:05 PM, wrote: > > Seems like a function > > pointer is more universal (I don't even need an object to be a receiver) > but > > maybe an interface is

[go-nuts] Re: About panic/recover in Golang

On Thursday, October 13, 2016 at 12:31:35 AM UTC+8, di...@veryhaha.com wrote: > > I don't like the spec docs for panic/recover in Golang, for the spec docs > is vague and not clear on when recover will take effect. > > So I wrote some examples to get the mechanism of panic/recover in Golang. >

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

On Wed, Oct 12, 2016 at 9:39 AM, Konstantin Khomoutov wrote: > On Wed, 12 Oct 2016 07:36:15 -0500 > John Souvestre wrote: > >> Interesting. I didn’t realize that thread was live again. I thought >> that this one put it to rest. >>

Re: [go-nuts] Re: Suggestions for parsing Forwarded HTTP Header (RFC 7239)

On Tue, Oct 11, 2016 at 10:08 PM, Tim Heckman wrote: > Hi Gophers! > > I ended up implementing a package for parsing the header. It didn't seem > like there was anything else purpose-built for it: > > * https://github.com/theckman/httpforwarded > The Gorilla Framework has

Re: [go-nuts] About panic/recover in Golang

On Wed, 12 Oct 2016 09:21:07 -0700 (PDT) d...@veryhaha.com wrote: > I don't like the spec docs for panic/recover in Golang, for the spec > docs is vague and not clear on when recover will take effect. [...] > So, it looks the calling of recover only takes effect only when both > of the following

[go-nuts] About panic/recover in Golang

I don't like the spec docs for panic/recover in Golang, for the spec docs is vague and not clear on when recover will take effect. So I wrote some examples to get the mechanism of panic/recover in Golang. // example A func main() { defer func() {

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Ø . The only reason I hesitate to go further is because that isn't formalized as part of the spec I don't believe, hence the issue. I believe it is. From the Go Memory Model: “To serialize access, protect the data with channel operations or other synchronization primitives such as

Re: [go-nuts] vim setup for auto go fmt on save.

As others said you can just add a command to BufWritePost. However don't forget that it's just runs it and is not able to capture any parse errors and show you. It also might replace your current buffer with the output of the error so you don't want it. Vim-go takes care of it and has many other

Re: [go-nuts] Architect a daemon program

On 11/10/16 18:09, Tong Sun wrote: > I've searched the mlist archive and have learned that I should > avoid daemonize as much as possible. So instead of label my program as a > daemon (or singleton or anything), let me describe what I need to do. > > I need the program (say, named as`myprog`) to

Re: [go-nuts] Re: go get: You are not currently on a branch

Dnia 2016-10-12, o godz. 02:37:16 Thomas Modeneis napisał(a): > You are not currently on a branch. Please specify which > branch you want to merge with. See git-pull(1) for details. This is common to freshmen to get a checkout of some tag then forget they did it. This

Re: [go-nuts] Re: go get: You are not currently on a branch

On Wed, Oct 12, 2016 at 2:27 PM Thomas Modeneis wrote: > Oh this is one of the problems that is really time consuming. I'm not sure if this is related, but I've never had this kind of problems before +1.7. Not being on a git branch is quite probably not caused by Go

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Interesting. I didn’t realize that thread was live again. I thought that this one put it to rest. https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ I don’t know for sure, but I imagine that Russ’ statement about atomics was mainly concerning synchronization –

Re: [go-nuts] Re: go get: You are not currently on a branch

this is more of a git problem, not a go problem. you're in a 'detached head' state and don't have a current branch to consider as your base. the best remediation is to issue 'git checkout master' in the respective repository. that will provide a correct head to work with. for more info:

[go-nuts] Function pointer vs interface for callback?

Hi, I've been writing some code where I have nodes in a processing graph that need to notify other nodes when something changes. I'm using callbacks (rather than channels, say) because I want everything to be synchronous. It seems like I've got a choice between type Foo struct {

[go-nuts] Re: go get: You are not currently on a branch

Oh this is one of the problems that is really time consuming. I'm not sure if this is related, but I've never had this kind of problems before +1.7. @Dave, I've tried your "quick-fix" but no luck ... $ go get google.golang.org/grpc # cd /opt/gocode/src/golang.org/x/net; git pull --ff-only You

[go-nuts] Re: go get: You are not currently on a branch

This issue is all over the web, people are having problems multiple times: http://stackoverflow.com/questions/33064343/go-get-git-error-on-all-sources-but-golang-org https://github.com/tools/godep/issues/60 https://github.com/golang/go/issues/6042

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

I mean https://github.com/golang/go/issues/5045 ons 12 okt. 2016 kl 13:50 skrev John Souvestre : > Ø I am sorry if I am dense but what Russ said in that thread "and that > you shouldn't mix atomic and non-atomic accesses for a given memory word" > seems to indicate

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Ø I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I’m not sure what thread you are referring to. In general it is best to avoid the sync/atomic stuff unless you *

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I am not going to use spin locks left and right but just understand the workings and adjust my expectations accordingly. ons

[go-nuts] Re: Survey - do you use Go in the cloud?

Andrew, Thanks for doing this. The Cloud Platform is great and I'm glad you're looking into this. Here are my 2c that didn't quite fit in the survey: when not running in a 'full' environment (lambdas/cloud functions, app engine, containers etc.), it would be good to keep the package/vendoring

[go-nuts] Re: package versioning

On Wednesday, October 12, 2016 at 2:04:19 AM UTC+2, Eric Johnson wrote: My view is that the general case requires putting such metadata in a > separate file for a package. > Yes, I agree with you that having multiple Go files with such comments creates repetition (having to update multiple

Re: [go-nuts] infinite loop makes program stuck

On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis wrote: > If you have multiple CPUs (and the Go memory model assumes that you > always can) they won't even write updated values from their cache out > to main memory until they hit a lock. > The reading CPU has read a value

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

I looked at pi/goal. It uses a sync/atomic CAS. Thus, yes, it provides a memory barrier. As someone else already recommended, the call to Gosched() for each loop will probably tie up the runtime quite a bit. It would probably be better to drop it entirely (if the spin isn’t going to last

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Sure that's my question. Does a SpinLock as given in several examples above provide the same semantics as a proper mutex? On Wed, Oct 12, 2016, 09:50 John Souvestre wrote: > Ø … state that one measly atomic load has the same memory effects as a > sync/lock which seems like

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Ø … state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? I believe that any of the atomic operations in sync/atomic is a memory barrier, just as a mutex is, and this is for all

RE: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

As I understand it, Go’s mutex lock will spin for a while (good if everyone using the mutex holds it for only very short periods), but will back off to a less compute intensive method after a while. This avoids tying up a CPU at the cost of some latency in seeing the other guy’s unlock.

RE: [go-nuts] infinite loop makes program stuck

I see that others have already addressed the locking issued, but I noticed something else. I don’t understand why you are using “select”. With only one case, I think that it’s normally going to fail and exit the select block, then loop due to the “for”. This will make it run constantly.

Fwd: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

Forgot the list, sorry. -- Forwarded message - From: Henrik Johansson Date: ons 12 okt. 2016 kl 08:32 Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and