Ghcide: Failed to start VSCode extension in Stack project

[NickSeagull]

Hey, thanks for this great effort. I've installed ghcide and it works when ran in the console for a newly created Stack project:

ghcide version: 0.0.4 (GHC: 8.6.5)
Ghcide setup tester in /home/nick/dev/ghcide-test.
Report bugs at https://github.com/digital-asset/ghcide/issues

Step 1/6: Finding files to test in /home/nick/dev/ghcide-test
Found 3 files

Step 2/6: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/6, Cradle 1/1: Implicit cradle for /home/nick/dev/ghcide-test
Cradle {cradleRootDir = "/home/nick/dev/ghcide-test", cradleOptsProg = CradleAction: stack}

Step 4/6, Cradle 1/1: Loading GHC Session

Step 5/6: Initializing the IDE

Step 6/6: Type checking the files

Completed (3 files worked, 0 files failed)

But when opening VSCode with stack exec -- code . I get the following error:

[Error - 1:27:16 PM] Starting client failed
Launching server using command stack exec -- ghcide --lsp failed.

Doesn't matter which command I configure in VSCode, ghcide, stack exec ghcide, or the stack exec -- ghcide --lsp, it always fails with the same error.

Any tips on how to debug this?

I'm running this under Ubuntu 18.04 under WSL.

[cocreature]

Try running stack install to install ghcide into ~/.local/bin, make sure that is in PATH (note that changes to PATH need to be visible to VSCode so if you change .bashrc make sure that you start VSCode such that it sees the changes (easiest might be to reboot)) and then set it to ghcide.

[NickSeagull]

Thanks for the suggestion! Sadly it didn't work :(

Any ideas about what could be the next steps? What additional information could I provide in order to help?

[cocreature]

What does which ghcide show you?
Also which folder did you open? You probably want to open the one containing hie.yaml.

[NickSeagull]

What does which ghcide show you?

~/dev/ghcide-test
❯ which ghcide
/home/nick/.local/bin/ghcide

Also which folder did you open? You probably want to open the one containing hie.yaml.

I'm opening the root of the newly created project, I added a hie.yaml containing the following with no avail.

cradle: {stack}

The tree -L 1 output is:

.
├── ChangeLog.md
├── LICENSE
├── README.md
├── app
├── ghcide-test.cabal
├── hie.yaml
├── package.yaml
├── src
├── stack.yaml
├── stack.yaml.lock
└── test

[cocreature]

I’m not quite sure what is going wrong. Are you sure that VSCode sees a PATH variable that contains ~/.local/bin?

[NickSeagull]

I guess? I created a VSCode task (created a .vscode folder and a tasks.json file) like the following, and it executes it properly:

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "echo",
      "type": "shell",
      "command": "ghcide"
    }
  ]
}

[cocreature]

I’m afraid, I’m starting to run out of ideas. This is using ghcide as the location of the executable and --lsp as the arguments in the extension settings, right?

[NickSeagull]

Yes @cocreature , perhaps running VSCode using the remote feature to connect to WSL doesn't play well with the extension?

[cocreature]

Oh yeah, I wouldn’t be surprised if that breaks.

[cocreature]

But you shouldn’t need WSL, ghcide should work natively on Windows.

[NickSeagull]

Lately I just default to WSL by default, as things usually work better on that side. I'm going to try seeing if ghcide works in Emacs, and in Windows, will report back 😄

[NickSeagull]

Ok, apparently Emacs connects properly to ghcide using eglot, trying VSCode from Windows now

[NickSeagull]

Apparently doesn't work on VSCode on Windows either.

What I've found is that if I run VSCode by using stack exec code, it will fail with the message above.
But if I run it out of stack, by just running code it will fail saying that it doesn't find ghc (which makes sense).

I just added to the PATH variable the ghc installation path and it worked. Still I believe that the errors are a bit misleading

[ndmitchell]

Sorry, I've got a bit lost with all the talk of WSL. Can you summarise what the problem was and how you fixed it? If possible, as a patch to https://github.com/digital-asset/ghcide/blob/master/docs/Setup.md? It would be good to collect whatever information you learnt from this adventure. Sounds like using WSL and remote connect are both bad ideas? If so, that seems worth documenting.

[NickSeagull]

@ndmitchell I've switched from WSL to regular Windows, but it still didn't work, what I ended up doing was adding C:\Users\nikit\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.5\bin to my PATH.

Now ghcide works, unless I open up a project that uses another version of ghc that is not 8.6.5.

I didn't close the issue because I don't consider this fixed. ghcide doesn't pickup the stack PATH in any environment on my side.

[cocreature]

This is related to https://github.com/digital-asset/ghcide/issues/137. Afaik, we don’t assume that GHC is in PATH ourselves but hie-bios does.

[Ciantic]

I was getting this in Windows: ghcide.exe: ghc: readCreateProcess: does not exist (No such file or directory)

And we figured a hack around for this:

VSCode user or workspace settings, add these:

    "hic.executablePath": "stack",
    "hic.arguments": "exec ghcide -- --lsp"

Since I use stack.

[jneira]

This might be solved in newer versions, that improves tool discovering (or you could use the haskell vscode extension)