Re: [go-nuts] [ANN] Elastic APM Go Agent

On Wed, 21 Mar 2018 at 13:34 Henrik Johansson wrote: > Out of curiosity is it Open Tracing compatible? > Not at the moment, but we are looking at both OpenTracing and OpenCensus. Which common/standard APIs we implement will depend on customer demand or community contributions. I expect at least

Re: [go-nuts] [ANN] Elastic APM Go Agent

Out of curiosity is it Open Tracing compatible? On Wed, Mar 21, 2018, 02:55 Andrew Wilkins wrote: > Hi folks, > > Elastic APM [0] is an open source APM solution being developed by Elastic. > The Elastic APM server [1] is written in Go. We've recently started working > on a package for tracing/mo

Re: [go-nuts] How to read a JSON Response body

Thanks! So using ioutil.ReadAll() followed by json.Unmarshal() can still be used, as this official example in the documentation shows https://golang.org/pkg/net/http/#example_Get But is less efficient than using json.Decoder().Decode() itself How should I handle the EOF case? On Tuesday

[go-nuts] [ANN] Elastic APM Go Agent

Hi folks, Elastic APM [0] is an open source APM solution being developed by Elastic. The Elastic APM server [1] is written in Go. We've recently started working on a package for tracing/monitoring Go applications: https://github.com/elastic/apm-agent-go. Although the Go support is fully functiona

[go-nuts] Go 1.10: how should I pass linker flags scoped to a single vendored package?

Like many folks, I often embed version information (git hash, build time, etc) into Go binaries with linker flags. Before Go 1.10, this worked: go build -ldflags="-X github.com/user/top_level_project/vendor/github.com/user/version.Version=some_hash" github.com/user/top_level_project After Go

Re: [go-nuts] Re: Long running task in select case

Yea looks a bit easier 👍 Kind regards Reinhard -- 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, vis

Re: [go-nuts] How to read a JSON Response body

Something to consider is that NewDecoder supports JSON streams, e.g. {"a": "b"}{"c": "d"}{"e": "f" } Each call to Decode will decode one object from the stream, but the underlying reader is not necessarily guaranteed to be at EOF. See: https://ahmet.im/blog/golang-json-decoder-pitfalls/ I don't h

Re: [go-nuts] implementation of sync.atomic primitives

On Tue, Mar 20, 2018 at 11:03 AM, shivaram via golang-nuts wrote: > > The race detector in v1.10 considers unsynchronized reads and writes on the > `int` and `bool` types to be races: > > https://gist.github.com/slingamn/886ebeba32f04294028cf0a60a8cc8c0 > > Are these instances of the race detector

Re: [go-nuts] How to read a JSON Response body

Hi! On Tue, Mar 20, 2018 at 10:37:40AM -0700, st ov wrote: > json.Unmarshal(resp.Body, &data) This one is invalid. > json.NewDecoder(resp.Body).Decode(&data) > > or > > b, _ := ioutil.ReadAll(resp.Body) > json.Unmarshal(b, &data) In the ReadAll case you'll have to allocate []byte in memory to

Re: [go-nuts] implementation of sync.atomic primitives

At risk of causing more confusion, here's my understanding of the situation after observing a lot of discussion about the memory model over the years. There are at least two different things one might mean when referring to the Go memory model: 1. The written contract as specified by the language

Re: [go-nuts] Re: About argument evaluation order.

On Tuesday, March 20, 2018 at 1:47:43 PM UTC-4, Ian Lance Taylor wrote: > > On Tue, Mar 20, 2018 at 8:52 AM, T L > > wrote: > > BTW, another problem: > > are the function calls appearing in a composite literal evaluated by > their > > lexical left-to-right order? > > Assuming you mean somet

Re: [go-nuts] Re: About argument evaluation order.

On Tue, Mar 20, 2018 at 6:48 PM Ian Lance Taylor wrote: > In this case I don't agree. The order of evaluation rules make it > clear that the first output is 1 and the last output is 2, but they do > not specify when the value of y is read. I see, I missed the "... and the evaluation of y is not

Re: [go-nuts] implementation of sync.atomic primitives

The race detector in v1.10 considers unsynchronized reads and writes on the `int` and `bool` types to be races: https://gist.github.com/slingamn/886ebeba32f04294028cf0a60a8cc8c0 Are these instances of the race detector being stricter than the memory model? On Monday, March 19, 2018 at 8:59:15

Re: [go-nuts] Re: About argument evaluation order.

On Tue, Mar 20, 2018 at 10:30 AM, Jan Mercl <0xj...@gmail.com> wrote: > On Tue, Mar 20, 2018 at 6:19 PM T L wrote: > >> Yes "1 1 2" is the output of gc, but I can't find any guarantees made for >> this output in Go specification. > > The guarantee was mentioned: LTR evaluation order as seen in the

Re: [go-nuts] Re: About argument evaluation order.

On Tue, Mar 20, 2018 at 8:52 AM, T L wrote: > BTW, another problem: > are the function calls appearing in a composite literal evaluated by their > lexical left-to-right order? Assuming you mean something like []int{f(), g(), h()}, then, yes. The order of function calls must be f(), g(), h(). Ia

Re: [go-nuts] About argument evaluation order.

On Tue, Mar 20, 2018 at 8:45 AM, T L wrote: > The Go specification only says > > In a function call, the function value and arguments are evaluated in the > usual order. > > The usual order is explained here: > https://tip.golang.org/ref/spec#Order_of_evaluation > But I am not clear on what the us

[go-nuts] How to read a JSON Response body

For JSON responses, is it more appropriate to use json.Unmarshal(resp.Body, &data) or json.NewDecoder(resp.Body).Decode(&data) or b, _ := ioutil.ReadAll(resp.Body) json.Unmarshal(b, &data) What are the uses for each? Does this differ from how you would read non-JSON responses? -- You rec

Re: [go-nuts] Re: About argument evaluation order.

On Tue, Mar 20, 2018 at 6:19 PM T L wrote: > Yes "1 1 2" is the output of gc, but I can't find any guarantees made for this output in Go specification. The guarantee was mentioned: LTR evaluation order as seen in the specs here: https://golang.org/ref/spec#Order_of_evaluation -- -j -- You r

Re: [go-nuts] Re: About argument evaluation order.

On Tuesday, March 20, 2018 at 12:38:25 PM UTC-4, Jan Mercl wrote: > > On Tue, Mar 20, 2018 at 5:18 PM T L > > wrote: > > > For the following example, the output may be any of "1 7 2", "1 8 2" and > "1 9 2"? > > The output is "1 1 2" due to LTR evaluation order mandated by the specs: > https://

Re: [go-nuts] Re: About argument evaluation order.

On Tue, Mar 20, 2018 at 5:18 PM T L wrote: > For the following example, the output may be any of "1 7 2", "1 8 2" and "1 9 2"? The output is "1 1 2" due to LTR evaluation order mandated by the specs: https://play.golang.org/p/WorzfBzfOhe -- -j -- You received this message because you are s

[go-nuts] Re: About argument evaluation order.

On Tuesday, March 20, 2018 at 11:45:02 AM UTC-4, T L wrote: > > The Go specification only says > > In a function call, the function value and arguments are evaluated in the > usual order . > > The usual order is explained here: > https://tip.

[go-nuts] Re: Enormously large core filed is generated for simple Go program.

Kindly discard this. I was looking at a different file. -- 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 option

[go-nuts] Re: About argument evaluation order.

BTW, another problem: are the function calls appearing in a composite literal evaluated by their lexical left-to-right order? On Tuesday, March 20, 2018 at 11:45:02 AM UTC-4, T L wrote: > > The Go specification only says > > In a function call, the function value and arguments are evaluated in

[go-nuts] About argument evaluation order.

The Go specification only says In a function call, the function value and arguments are evaluated in the usual order . The usual order is explained here: https://tip.golang.org/ref/spec#Order_of_evaluation But I am not clear on what the usual

[go-nuts] Enormously large core filed is generated for simple Go program.

Hi, For a simple program: package main import ( "fmt" "os" "time" ) func main() { fmt.Println("hello!", os.Getpid()) time.Sleep(10 * time.Second) } I generate the core file using "gcore ". Size of the core file is 1.1G. Is that normal? Isn't it eno

Re: [go-nuts] Necessary to use sync.pool for gc in golang 1.9

On Mon, Mar 19, 2018 at 10:51 PM, 芮峰云 wrote: > Necessary to use sync.pool for gc in golang 1.9 ? No. It's never necessary to use sync.Pool. sync.Pool is a special purpose mechanism for more efficient handling of certain memory allocation patterns. It is not a general purpose tool. Ian -- Yo

[go-nuts] Necessary to use sync.pool for gc in golang 1.9

Necessary to use sync.pool for gc in golang 1.9 ? -- 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, vi

Re: [go-nuts] Re: Long running task in select case

It’s channels either way: https://play.golang.org/p/OTNPsxiDSOp A difference is no access to context.Context.Err(), but in this example the error isn’t checked. My opinion is there’s no reason to bring in the whole context when all that’s needed is a cancel action. Also there’s an added compile

[go-nuts] Re: go1.10.windows-386.msi have securityalert in ESET

Thank you very much! 2018年3月20日火曜日 22時00分00秒 UTC+9 Alberto Donizetti: > > Likely a false positive from your antivirus. See: > > https://tip.golang.org/doc/faq#virus > > A. > > Il giorno martedì 20 marzo 2018 04:48:21 UTC+1, sa koji ha scritto: >> >> when install go1.10.windows-386.msi、eset do sec

[go-nuts] Re: go1.10.windows-386.msi have securityalert in ESET

Likely a false positive from your antivirus. See: https://tip.golang.org/doc/faq#virus A. Il giorno martedì 20 marzo 2018 04:48:21 UTC+1, sa koji ha scritto: > > when install go1.10.windows-386.msi、eset do security alert. > does this have solved problem? > -- You received this message because