[go-nuts] cmd/vet false positive on a context.WithTimeout

Hello, I'm having go vet complain about the cancelFunc on a context.WithTimeout not being called, even though the flow path is already past the context .Done() Something like: ctx, cancel := context.WithTimeout(parentCtx, timeout) select { case <-ctx.Done(): //... go vet complains here

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

Go is statically compiled. Pretty sure you cant do dynamic instrumentation - like logging method entry and exit - much of this is even lost due to inlining. You could possibly have an instrumented stdlib and dynamically link to that, but that is still not dynamic instrumentation. The profiler

Re: [go-nuts] New Modules and git clones

Russel, Just two add a quick doc reference: The general capability being discussed here is called "module queries". This section of the doc is probably worth a quick read or re-read: https://golang.org/cmd/go/#hdr-Module_queries Module queries provide a fair amount of flexibility, and allow

Re: [go-nuts] About source folder organization

Hello Volker! Thanks for your feedback. The overthinking is direct consecuencie of two things: having time and don't have TV at home :P. I have a felling that what you are trying to say me is to: just forget a little bit over the underlying storage system for the files, and focus only in the

Re: [go-nuts] About source folder organization

Thanks for pointing that out. *V* El jue., 15 nov. 2018 a las 12:56, Jan Mercl (<0xj...@gmail.com>) escribió: > On Thu, Nov 15, 2018 at 4:51 PM Victor Giordano > wrote: > > > You may say that i'm a little stubborn but what after i look at others > source files i do notice that they do not

Re: [go-nuts] New Modules and git clones

> The `dev` in that documentation is intended to be a branch name. If that > module doesn't actually have a branch named `dev`, it won't work. Thanks for humouring my stupidity :) Because as if to reinforce the fact that I've never seen that help document, I've also successfully demonstrated

Re: [go-nuts] About source folder organization

On Thu, Nov 15, 2018 at 4:51 PM Victor Giordano wrote: > You may say that i'm a little stubborn but what after i look at others source files i do notice that they do not reference "childs" packages from "parents" > (please allow me to use those words, again...)or can you tell me of the opossite

[go-nuts] Re: cmd/vet false positive on a context.WithTimeout

Jaime, AFAIK, cancellation function is expected to be called regardless of if ctx.Done() got triggered. So, to fix it, drop a direct call to cancel() and add "defer cancel()" right after you got it from the "WithTimeout" call. Hope it helps, Andrey On Thursday, November 15, 2018 at

[go-nuts] [RFC] Dynamically instrumentation Go binaries

Hi, I am working on dynamic instrumentation of Go programs at run time, possibly without static source-code instrumentation. As I would like a solution as close to Go and standard as possible, I was first thinking of using `go generate` to generate a file adding things `reflect` doesn't

[go-nuts] blocking profile

Hello, I'm using four channles, and some TCP connections. It works and one point my server does not get the data over tcp connections.rr Still No fatal error or panic error I tried here and there. Finally I did blocking profile. I show some data. I run $go tool pprof -svg main

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

You could study Rob Pike’s coverage/profiling tool to see how he adds and exploits basic block counting. Good work as always. On Thu, Nov 15, 2018 at 9:34 AM Robert Engels wrote: > AFAIK dtrace support is compiled in. If not enabled there are some tricks > to make is essentially zero cost, but

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

Maybe you mean something like support for linux uprobes? There is some discussion here: https://github.com/golang/go/issues/22008 Google for "golang uprobes" picks up a couple of other links: http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

Can’t you just ptrace the process, and use the ptrace related tools ? > On Nov 15, 2018, at 2:56 PM, Tristan Colgate wrote: > > Maybe you mean something like support for linux uprobes? > There is some discussion here: > https://github.com/golang/go/issues/22008 >

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

Even if you could get uprobes to work, I think you will still have problems with inlining, and if you are going to compile with inlining disabled, etc. you might as well use Pike’s “coverage” method. > On Nov 15, 2018, at 3:23 PM, robert engels wrote: > > Can’t you just ptrace the process,

Re: [go-nuts] About source folder organization

For your information people, i'm trying to open my mind for embracing the concept of packages without any trace of the hierarchical relation of underlying file system in mind! Thanks again for your valuable opinions. I really needed someone to talk about this, i love doing code/patterns/idioms

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

Pike’s “coverage" uses source code rewriting and recompiling, so it is not dynamic instrumentation - at least how I would define it. Dynamic instrumentation to me means to instrument at runtime on an existing binary/distribution. > On Nov 15, 2018, at 12:55 PM, Michael Jones wrote: > > You

Re: [go-nuts] About source folder organization

Jan, Volker... i will try you to summon over here ! There is another person with some kind of the same problems i were... he is trying to organize code in packages and maybe overthinking. El jue., 15 nov. 2018

[go-nuts] error on using protoc command for generating .pb.go file

Hi everyone, I get the following error while running : protoc --go_out=. test.proto error: github.com/gogo/protobuf/gogoproto/gogo.proto: file not found import "github.com/gogo/protobuf/gogoproto/gogo.proto" was not found or had errors. The file definitely exists on the imported path. I read

[go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

One approach would be to augment the compiler to instrument the binary with the techniques outlined in: XRay: A Function Call Tracing System https://ai.google/research/pubs/pub45287 Damian On Thursday, November 15, 2018 at 9:09:19 AM UTC-8, ju...@sqreen.io wrote: > > Hi, > > I am working on

[go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

If you can't recompile the binary, an option is to use a generic dynamic instrumentation platform like DynamoRIO (which I think works for Go programs after a recent bugfix). It works on windows, mac, and linux, and has been used in the past for various

[go-nuts] slow running job

I am running a service (web) type job. It takes 30-40 secs for the job to start up when I do it manually. Is there anything in nomad which will kill the job if it doesn't start in X secs? I am having a strange issue where the job starts up sometimes and sometimes it fails. If I do nomad

[go-nuts] Joke in the air :D

It reached it's "golden years" -- 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

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

dtrace support? On 15/11/2018 16:51, ju...@sqreen.io wrote: Hi, I am working on dynamic instrumentation of Go programs at run time, possibly without static source-code instrumentation. As I would like a solution as close to Go and standard as possible, I was first thinking of using `go

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

AFAIK dtrace support is compiled in. If not enabled there are some tricks to make is essentially zero cost, but it is still there from the start. Could be wrong but that’s my understanding. Sent from my iPhone > On Nov 15, 2018, at 11:27 AM, Steven Hartland wrote: > > dtrace support? > >>

Re: [go-nuts] About source folder organization

Ooops: This should read It simply does *NOT* influence the one and only package rule. On Thursday, 15 November 2018 09:04:01 UTC+1, Volker Dobler wrote: > > My opinion on this: You are overthinking it. A lot. > > Let's start simple. Cyclic dependencies between packages > are disallowed and

Re: [go-nuts] About source folder organization

My opinion on this: You are overthinking it. A lot. Let's start simple. Cyclic dependencies between packages are disallowed and whatever you do you packages must not for an import cycle. This is the only hard rule. Note that this rule is totally decoupled from the filesystem layout of your

Re: [go-nuts] New Modules and git clones

On Wed, 2018-11-14 at 15:36 -0800, 'Bryan Mills' via golang-nuts wrote: […] > The `dev` in that documentation is intended to be a branch name. If that > module doesn't actually *have* a branch named `dev`, it won't work. […] Bingo. I put require ( github.com/jamalsa/qml master

Re: [go-nuts] New Modules and git clones

> > The `dev` in that documentation is intended to be a branch name. If that > > module doesn't actually *have* a branch named `dev`, it won't work. Thanks, Bryan. > ... > > Hopefully there is a way of this getting updated as master/HEAD gets more > commits. Not automatically, no. go get