I believe these are fantastic choices.
I have given two presentations to Go meetups about the draft generics
design in the last month. The second time was after the square bracket idea
was added to the prototype and someone suggested the other parts adopted in
item #1. In that second
go run works now too and pulls in all the files in the package at
so "go run ." is a nice shortcut that works more like the other
subcommands of the go tool.
On Thursday, October 24, 2019 at 8:17:54 AM UTC-4, Guy Allard wrote:
>
> Use:
>
> go run *.go
>
> or
>
> go build *.go
>
>
> On
I am pretty sure that a "proc" in the trace visualization output is the
same as a "P" in the parlance of the Go runtime scheduler. In the scheduler
an OS thread is an "M" and even when using LockOSThread the locked
goroutine and thread need to be paired up with one of the scheduler's Ps in
You might be able to find an answer to your question in this article:
https://github.com/go-modules-by-example/index/tree/master/016_major_version_repo_strategy
On Tuesday, August 27, 2019 at 6:31:57 AM UTC-4, Jason E. Aten wrote:
>
> With an eye towards implementing semantic import path
Have you seen: https://github.com/sonatype-nexus-community/nancy
"A tool to check for vulnerabilities in your Golang dependencies, powered
by Sonatype OSS Index"
On Wednesday, August 14, 2019 at 1:02:03 AM UTC-4, Eric Johnson wrote:
>
> And then, it also occurs to me that perhaps I can answer
On Thursday, August 17, 2017 at 3:14:09 AM UTC-4, Henrik Johansson wrote:
>
> Sorry to but in but what happened to the whole logging initiative that was
> on going?
> Did I miss something about that? It seems very related to this.
>
That discussion took place in this thread:
kage. That said, designing private libraries as if they
were public libraries could be a good idea in the long run.
Chris
On Tuesday, August 15, 2017 at 12:09:44 PM UTC-4, Sam Vilain wrote:
>
> On 8/15/17 7:14 AM, Chris Hines wrote:
>
> I would be curious what you think o
I would be curious what you think of github.com/go-kit/kit/log (and related
"sub"-packages). See my talk about it's design here:
Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw
Slides: https://speakerdeck.com/chrishines/go-kit-log-package
Chris
On Monday, August 14, 2017 at
This discussion points out another nomenclature problem in the list. What
the list refers to as a "Package comment" is actually a "Canonical import
path" comment. See https://golang.org/doc/go1.4#canonicalimports
Package comments (as defined in this blog
post:
The code shown for "User decorator pattern" is more properly known as the
"Functional options" pattern. I think this talk demonstrates the decorator
pattern more correctly: https://www.youtube.com/watch?v=xyDkyFjzFVc
On Monday, July 31, 2017 at 12:15:18 PM UTC-4, ha...@arne.me wrote:
>
> Hey, I
See also: https://github.com/golang/go/issues/10958
On Wednesday, June 21, 2017 at 1:12:12 AM UTC-4, Ronald wrote:
>
> I found this: https://github.com/golang/go/issues/7190.
>
> Then I replace :
>
> go func() {
> for {
> }
> }()
>
> With:
>
>
> go func() {
> ct := 0
>
The infinite loops in each function will busy loop and consume a core
without allowing the runtime scheduler a chance to run other goroutines on
that core. If your virtual machine doesn't have enough cores then some
goroutines may starve.
Change the loops to select {} to block infinitely
I believe the primary reason why select must be in the language is because
it integrates tightly with goroutine scheduling to efficiently block, and
then wake up when one of its channel operations can complete.
On Thursday, January 19, 2017 at 12:33:38 PM UTC-5, John C. wrote:
>
> On several
142
> var i2 = float64(3.142)
> i3 := float64(3.142)
>
> The float64 casting is unnecessary in the latter two cases, but it isn't
> an error.
>
> On Thursday, 15 December 2016 21:01:11 UTC+5:30, Chris Hines wrote:
>>
>> Suppose instead of `json:"s,string"` you had
Suppose instead of `json:"s,string"` you had typed `json:"s,omitemptyy"`
when you meant to type `json:"s,omitempty"`. Would you want to be told that
you had an error in your struct tag? In general Go has a fail-fast
philosophy to help prevent mistakes from persisting in a system unnoticed
for
I agree with the sentiment that putting these options in context.Context
values is inappropriate.
Chris
On Friday, December 9, 2016 at 7:14:03 PM UTC-5, Dave Cheney wrote:
>
> I agree with this. This feels like a case of abusing the "bag of values"
> nature of context's Value() feature to
I tried to break down the thought process on this exact question earlier
this year and gave a presentation at my local Go meetup. My slides are here:
http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide
FWIW, I'm a big fan of gopkg.in/tomb.v2. For similar functionality using
contexts consider golang.org/x/sync/errgroup.
On Wednesday, November 2, 2016 at 7:55:59 PM UTC-4, Gustavo Niemeyer wrote:
>
> You said the function would return whether it got cancelled or not, so I
> assumed something
Slight improvement:
1. Rotate usernames/passwords and call sql.Open(...) to get a new
connection pool for future queries. (Save old pool in oldDB.)
2. Call oldDB.SetMaxIdleConns(-1), which will immediately close any unused
connections in the old pool and cause those in use to be closed as soon
db.SetMaxIdleConns(-1) will flush cached connections. That leaves the
problem that open connections still in use will not get closed until
returned to the pool, and only if caching idle connections is still
disabled at that time.
Changing credentials on an already open *sql.DB isn't directly
If you want to dig into this topic more. I gave a presentation on this
topic at my local Go meetup earlier this year.
The slides from my talk are
here:
http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide#1
Some of the code
I'm pretty sure that the last few versions of Go (since 1.5 maybe) are smart
enough to do it automatically. I believe the .o files in the pkg tree have the
compiler version embedded in their meta data for this purpose.
--
You received this message because you are subscribed to the Google
On Monday, September 12, 2016 at 8:57:15 AM UTC-4, Markus Zimmermann wrote:
>
> Hi gophers!
>
> I am wondering why we have a "declared and not used" compile error for
> variables [https://play.golang.org/p/KLzHVO5L7q] but not for constants [
> https://play.golang.org/p/JG9dSa_VKg]? I am sure
There was some discussion about how to handle generated methods in stack
traces in #11432, in particular I brought it up in this
comment: https://github.com/golang/go/issues/11432#issuecomment-146269822.
The discussion eventually led to the addition of the new
runtime.CallersFrames API, but
The history of this behavior is explained in the release notes for Go
1.3: https://golang.org/doc/go1.3#map
On Friday, June 24, 2016 at 8:48:20 AM UTC-4, Val wrote:
>
> 2 implementations here :
> http://www.programming-idioms.org/idiom/10/shuffle-a-list/1564/go
>
> As for the map iteration
25 matches
Mail list logo
