No autocompletion when using it on my Mac (Intel)

[oderwat]

The problem is that I do not get auto-completion when running it on my Mac.

I compared the Colab version vs running locally and running through docker on the Mac. I got the code completion only using the Colab notebook. Which makes me wonder. Shouldn't the docker image work too? I am also on an Intel Mac, so the image should just run as everywhere.

I used it with Jupyter installed through homebrew, through conda with a manually pip install and through conda with the official jupiterlab installation.

I am going to check everything on Linux and Windows too.

[oderwat]

While writing the above, I found the solution for my problem, which is a bit hilarious:

I had to go to the settings editor and enable auto-completion. But I also realize that I may be supposed to press TAB to get the completion :)

@janpfeifer I am going to test if that works with the go.work files.

[oderwat]

This is still a bit shaky, slow and gives the wrong responses or none at times. Even when I see the console displays that there are probably the right answers. For example, I get "complete_reply: ok, 29 matches" in the console and the notebook shows "fmt" in the pop-up. More often, it does not show anything at all. Occasionally, it even shows the whole notebook in the popup (yikes).

I think I stop fidling with that for now, I felt okay without caring about the gopls integration working right :)

I am uncertain if that helps in any way. For me, the whole thing worked better without worrying about the completions xD. I may just switch them off.

EDIT: I found out, that if it is working or not seems to depend on what I have in the cell. Not sure what it is, but in a fresh and shorter cell it works. It seems as if the "code" works and compiles, but the gopls still has the wrong information or something like that.

[janpfeifer]

Thanks, I observed similar things here (without go.work), but I thought I had fixed them all.

Btw, the auto-complete will also run goimports, if it feels it needs to install a library (based on a package name typed). And that, if it is the first time, can be slow, since it fetches it and installs it.

I'll try out with go.work and see if I can make it work. Thanks for trying @oderwat .

Btw, while using Jupyter to code, something else that I find very useful is the "shift+tab", which brings in a pop-up, the information about the function under the cursor (or being called) -- I always use it to remember the parameters of the functions.

[janpfeifer]

hi @oderwat ,

I think I found the issue with go.work: I should have looked at it earlier (I had even left a TODO ... my bad). I actually needed to parse the go.work and track (recursively) all the directories listed in the use clauses -- I do something similar with the go.mod "replace" clauses.

I also fixed a bug where cells that had no %% or no func main() defined auto-complete wasn't working -- i didn't notice it earlier.

Would you like to test it ? It is submitted in main, but to test you have to clone locally and do a go run . --install.

Or, for debugging I use instead (requires a restart of the jupyter-lab):

go run . --install --logtostderr --vmodule=parser=2,inspect=2,composer=2,goplsclient=2,conn=2,track=2,tracking=2,execcode=2

Then you get logs of everything that is going on.

But also, if you don't care, I'll create a v0.7.1 release tomorrow (with a new docker), and you can try there -- hopefully it will be working.

This doesn't solve Mac installation though :\ ....

ps.: I just noticed also that gopls only works with go.work on version 0.12 and above -- I had to updated it here. I should try it and add a warning on version I suppose.

[janpfeifer]

Nit: I also updated the tutorial with the go.work example (inline with the example you provided)

[oderwat]

Nice. I am short on time, but will definitely check it out this weekend. I have no problem with installing it through main, and using docker is not an option until I add credentials and setup for the private repositories.

P.S.: I also made a build tool that checks 'go.work' files and parses all the packages that could get changed for a recompile watcher. I guess gopls is quite similar in some respect.

[janpfeifer]

I tested some more, fixed a bit the documentation and docker, and decided to move ahead and cut and release the v0.7.1 version.

I hope it works fine (everything was working as far as I tested), but if not I can always do another release.

cheers

[oderwat]

@janpfeifer sorry for me not reporting back. I had no chance to check back on your cool project until yesterday. It is all working very nice now!

P.S.: Is there a way to get gofmt running in the cells? Meanwhile, I may create an Alfred workflow for me to format the cells.

[janpfeifer]

No probs, actually I just found an issue with go.work: GoNB before executing every cell, runs go get, just in case, to fetch any potential missing libraries -- usually everything is in the cache, so this adds imperceptible latency, and makes things great for users.

Problem is, go get doesn't seem to follow go.work use directives, and instead try to find a module's packages on the github source. This has no impact if the package exist in the remote (github's) location, but it fails if the package only exists on the use directory, I'm still considering how to solve this ... I could just ignore go get errors when there is go.work and move forward ... Oddly this is not an issue with go.mod redirects.

About the gofmt in cell: I've searched before, but I don't think in Jupyter's protocol there is any way for the kernel to tell the notebook to replace the cell with new content.

I wonder if we could try to run this on Jupyter, as a javascript plugin (with a go fmt compiled to WASM). Or ... reach out to the Jupyter folks: it is also an editor, I think they may have interest in doing things like that ? It would be a very neat feature!

[oderwat]

@janpfeifer

About the go.work: Yes. I had this happen today (together with some strange multi-repo stuff I still did not figure out). In the end, I rewrote that repository and pushed the changes to not waist so much time with it.

BTW: I found this while searching if that is an inherent problem with the go tool chain: https://youtrack.jetbrains.com/issue/GO-12288/Do-not-run-go-list-with-modmod-flag-if-go.work-exists

About the formatting: Besides off WASM, one could use GopherJS and just use Tampermonkey (Userscripts) to modify the page on the fly. See https://dmitri.shuralyov.com/blog/24. But I think it would be much better if that could be part of the Jupyter-Lab API. Python is much harder (impossible) to autoformat, this may be a reason why this is not considered in the API.

[janpfeifer]

Funny that the issue you linked has some comments of mine. Unfortunately, I think it's not related.

But I posted a question in the gonuts mailing list:

https://groups.google.com/g/golang-nuts/c/2Ht4c-eZzgQ

Hopefully, someone will know how to handle this, and I'll fix it soon.

On the gofmt front, let me know if you would be willing to investigate the Jupyter protocol for that. Whatever is needed on the GoNB side (for instance running the gofmt on the code -- and converting back and forth from "%%" to "func main()", etc.) I'm happy to help.

cheers

[oderwat]

@janpfeifer Funny that the issue you linked has some comments of mine. Unfortunately, I think it's not related.

Yes, I mentioned it because I found it funny too.

Currently I do not have time to investigate the gofmt, but I keep it in mind.

[janpfeifer]

I just released v0.7.3, which includes a special command %goworkfix that creates go.mod replace clauses automatically for each module in your go.work use directories. Just run it after making changes to go.work.

I also parse go get errors, and if GoNB notices the issue, it outputs a note explaining the situation and how to fix it, so it's not so mysterious.

I updated the tutorial as well to reflect that.

This is just a work around. Hopefully at some point go get will not need it.

cheers