Closed Dieterbe closed 1 month ago
Thank you for this thorough investigation, but you are right to say that we will not be fixing guru issues. gopls
is close to reaching beta, so it is the recommended alternative. If you are interested in using CLI tools, you can also try gopls implementation
command, which will tell you both the implementations of a given interface or the interfaces implemented by a concrete type.
guru was deleted in https://github.com/golang/go/issues/65880; closing as obsolete.
Hello, first of all, thanks for the work that's been put into guru. It's certainly been quite helpful to me over the years. I know
guru
is no longer actively maintained (and I don't expect a resolution), but considering gopls is still in alpha, i thought it might be helpful to others (or to my future self) to document this issue.What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputI found out that based on the working directory when
guru implements
is run, it can take an extreme amount of cpu and take a very long time.In particular, consider these 3 types of runs:
only 1) returns in a reasonable amount of time. 2) is how visual studio code invokes it (when CWD is
$GOPATH/src/github.com/prometheus/prometheus
), and 3) is my attempt to fix the problem with 2) by constraining the scope.More info about each run:
Note: I moved
guru
toguru-real
and replacedguru
with this script:this allows me to track the exact environment of the process each time it is run (particularly when the parent is vscode and not my terminal), but it turns out the issue was reproducible perfectly from a terminal, so at this point it's no longer useful, but it does explain why i have mentions of "guru-real" in the
pstree
output below.run 1
run 2
I didn't let it complete. I killed it after it ran for hours.
run 3