Open dlsniper opened 8 years ago
Seems like it shouldn't be so hard to invoke gocode close
when the package is deactivated, but I don't think we want to run an asynchronous tool lookup when we're shutting down.
What if instead of looking for the gocode
executable multiple times, we looked for it once and then cached it? What say you @joefitzgerald
I'm on the macOS Sierra beta, and there's a slightly bigger problem - I seem to have hundreds of gocode processes running. I'm only working on a few Go files at a time, less than 10. Need to keep killing them manually.
@sudhirj yikes! Makes me wonder if it's an issue with go itself? I've seen a few Sierra - specific changes in go 1.7 RC1. Seems like the gocode autocomplete daemon is failing to find itself so it's launching and daemon using every time.
One way to rule this out is to close all instances of gocode, then launch it in server mode (gocode -s
) and see if that stops the issue. If it doesn't, it's probably a gocode or a go issue.
@sudhirj are you still experiencing your issue with multiple gocode processes? I'm running on macOS Sierra beta now, and not experiencing the issue. Try gocode close && go get -u github.com/nsf/gocode
after installing go 1.7
?
No, haven't seen the problem in a while.
@joefitzgerald I have seen this on linux right now.
Sry, my response was not related to the discussion, I have read it a bit too fast, I apologize for that. :)
Hi there :wave:
I've gave Atom 1.7.1 + go-plus 4.1.0 (with autocomplete-go 1.0.6) a spin tonight on my Kubuntu 15.10 x64 machine. I've noticed that after I close the IDE gocode will still linger in memory and I have to terminate it explicitly. Please let me know if I can help out with anything to fix this. Thank you.