Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gocode completely doesn't work since version golang 1.10 #509

Open
monoflash opened this issue Apr 2, 2018 · 12 comments
Open

Gocode completely doesn't work since version golang 1.10 #509

monoflash opened this issue Apr 2, 2018 · 12 comments

Comments

@monoflash
Copy link

Gocode completely doesn't work since version golang 1.10.
The utility does not return anything after updating golang.
If roll back golang to version 9, then everything starts working again.
:(

@nsf
Copy link
Owner

nsf commented Apr 2, 2018

Might help: #500

tl;dr: Go has package cache now, with 1.10 you can with hacks make gocode work, but in the long term who knows what happens next. Start looking for alternatives or hope and pray that I'll end up writing next version of the gocode relatively soon (probably it will have a different name).

@kovetskiy
Copy link

@nsf if you are going to write new version of gocode that will work with source code (instead of package cache), can we cooperate on this task? I don't really want to do it alone and maintain it for years, but it could be easier if several developers would work on that task at the same time.

@nsf
Copy link
Owner

nsf commented Apr 3, 2018

@kovetskiy no, due to unpredictable schedule I don't see how it's possible. I might be coding it every day for a week and then doing zero progress for a few weeks, etc. That's just how open source works. there is nothing to colaborate over until there is a major codebase written and ready. Next gocode will be most likely called "gls" which stands for Go Language Server or Service. It will most likely implement the langauge server protocol by sourcegraph. E.g. similar to: https://github.com/sourcegraph/go-langserver. But having a compatibility mode in mind if possible for existing gocode text editor integrations. What I want is to take full advantage of this protocol and implement everything starting from syntax/semantic checks, goto, "codelense", find usages of, autocompletion, quick fixes, etc. It's a lot of work, but it needs to be done this way and no other way is acceptable. Proper and full source language server protocol implementation.

P.S. If you don't want to maintain it, then don't do it at all.

@kovetskiy
Copy link

@nsf I mean that I don't want to maintain it if I would be alone as you do with gocode. That's the difference.

@nsf
Copy link
Owner

nsf commented Apr 3, 2018

Well, listen, when and if I have some code to show, then we can talk about collaboration. It's pointless to collaborate over something that doesn't even exist yet. I don't know how it will look, what kind of libs it will use, what it will do exactly, etc. And I don't want to discuss those details either.

@kovetskiy
Copy link

@nsf ok, no problem, just ping me if I have a chance to help you with any related issue. I will be glad to make a contribution.

@mdempsky
Copy link

mdempsky commented May 2, 2018

FYI, I just added a -source flag to mdempsky/gocode to make it generate suggestions from source, instead of from compiled package definitions.

Caveat: the main branch of mdempsky/gocode doesn't implement any caching. For compiled imports, this is moderately slower (but IMO still acceptable for interactive use, ~200ms in large packages), but source imports are substantially slower (~1.5s for each completion, even in small packages).

I've prototyped caching in the cache branch. It's currently for compiled packages only (and standard cmd/go workspaces; no gb support), but it brings performance on par with nsf/gocode: ~30ms to ~40ms when cached.

I'd really like to implement this functionality directly into a langserver implementation so that it can make use of langserver's VFS functionality.

@nsf
Copy link
Owner

nsf commented May 2, 2018

Added a link to "mdempsky/gocode" to README.md. Hopefully @mdempsky, you don't mind.

@nsf
Copy link
Owner

nsf commented May 2, 2018

Although I understand that you don't have a magic fix for "package cache" problem yet. The chance that you'll have one is much higher than on my end. The "-source" flag thing looks interesting.

@nsf
Copy link
Owner

nsf commented May 2, 2018

Sorry for message spam, but to clarify a bit what I think here. Basically in short term if new Go binary packaging changes affect you (e.g. you don't use alternative build tools such as https://getgb.io, also I don't want to say that I recommend it, it just happened this way that I'm stuck with it), then consider looking at @mdempsky fork of gocode. Since that fork can parse source files already for imported packages, maybe it will get proper caching as well sooner or later which will make it also not as slow as it is right now. This (my) repo however will probably never get those "package cache" workarounds.

In long term - we need better tools for Go ecosystem. I was writing a bit of typescript recently, I'm very happy how their language service protocol integration works with vscode. We need something like that, but preferrably faster (at least as much as it depends on language service itself). I know some people do some stuff, other people do other stuff. I'm working on something as well, but it's very early to announce anything.

@mdempsky
Copy link

mdempsky commented May 2, 2018

@nsf Thank you for the link. I don't mind.

@localvar
Copy link

localvar commented Jun 1, 2018

@mdempsky , I implement a source caching based on your master branch, at localvar/gocode. I hope I could send a PR to you, but seems too difficult for me to do everything right, though I think it works in most cases.

the current issue is memory consumption, need find out a way to avoid duplicated packages

the above issue should be fixed by implementing a new importer, most of the code is copied from go/internal/srcimporter, the major change is moving package cache from instance level to global to allow the reuse of already parsed packages.

because context (GOOS, GOARCH and etc.) is specified in every completion call, it is possible that the cached packages are in different contexts, this may lead to wrong suggestion result. but I don't think context changes frequently, so this should not be a big problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants