> What would you suggest 'go get' can do to "do better"?
I hate comparing Go with Node, but (I'm sorry)... How about doing the same
that NPM does ? NPM installs the target module + target version. End.
On Thursday, October 13, 2016 at 7:31:37 AM UTC+2, Jan Mercl wrote:
>
> On Thu, Oct 13, 2016 a
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 received this message becaus
You are right. I misread that totally. Thanks!
John
John Souvestre - New Orleans LA
From: Matt Harden [mailto:matt.har...@gmail.com]
Sent: 2016 October 12, Wed 20:03
To: Minglangjun Li; John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] infinite loop makes program stuck
On We
Versioning for the scripts is now in, so no need to run with -r to
regenerate scripts (
On Tuesday, October 11, 2016 at 4:57:52 PM UTC-4, Nate Finch wrote:
>
> Next on my list is adding versioning to the generated scripts so you never
> have to worry about whether a script is old or not.
>
> Als
On Wed, Oct 12, 2016 at 5:56 PM, Thomas Modeneis wrote:
> The main problem seems to be related to go get believe me or not.
>
I kind of agree, in the sense that what we did, was purely "go get", and
never tempered with the git underneath. You can blame git, but I think "go
get" can do better to a
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 cache out
> to main memory until they hit a lock
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 th
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 > napis
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 believe
There is a short blog at
https://suffolkgophers.github.io/dotgo2016.html
--
4096R/EA75174B Steve Mynott
--
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
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:
> >
> >> Interesting. I didn’t realize that thread was live again. I thought
>
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 more idiomatic?
>
> An interesting patter
I think there are two main difficulties
- Having a good tool to extract an accurate communication model from
source code is actually very difficult because of the flexibility of Go,
like calling an interface function without knowing which implementation to
use - this could change th
On Wed, Oct 12, 2016 at 9:21 AM, 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.
>
> // example A
> func main() {
>
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.
>
On Thursday, October 13, 2016 at 1:08:41 AM UTC+8, Konstantin Khomoutov
wrote:
>
> On Wed, 12 Oct 2016 09:21:07 -0700 (PDT)
> 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.
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.
>> https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nK
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 middleware for handling
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 t
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.
> https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ
>
> I don’t know for sure, but I imagine that Russ’ statem
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() {
fmt.Println(recover()
Ø . 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 th
So mixing atomic read/write of one variable makes non-atomic read/writes of
another variable safe as well? As far as the memory model goes? Caveat
being that it's not formalized.
I am sure great care is needed when attempting such code regardless...
On Wed, Oct 12, 2016, 16:04 wrote:
> I think
I think what Russ is saying there is don't do
// routine 1
x = 5
// routine 2
atomic.LoadInt32(&x)
That's mixing atomic operations on the same word. In the case of a spin
lock to coordinate threads, Dmitriy's comment 15 is illustrative:
1.
// goroutine 1
data = 42
atomic.Store(&ready, 1)
//
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 sm
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
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 is a root cause of update f
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 more idiomatic?
An interesting pattern from the http pkg is that a function type can
also implement an interface.
https://golan
On Wed, Oct 12, 2016 at 5:05 AM, wrote:
>
> 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 ch
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 (regardless of
version).
> @
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 – whic
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:
http://st
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 {
Callback
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 ar
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
http://stackoverflow.com/questions/30188499/how-to
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 otherwise.
>
>
>
> I’m not sur
Ø 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 * rea
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
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 co
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 fi
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 from main memory and put
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
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 it might work on some
Ø … 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 platforms
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.
Joh
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.
I
46 matches
Mail list logo
