Error trying to use vscode extension in windows 10

[jneira]

Hi! I am trying to check the recent lsp support for unison in windows 10 and i am getting an alert in vscode:

Unison: Language server failed to connect, is there a UCM running? (version M4a or later)

My tools versions:

• extension: v0.0.6
• ucm: release/M4b

Extension config:

"unison.lspPort": 5757
"unison.trace.server": "verbose"

I dont see any log entry in the unison output pane ot the running ucm console I've checked i can access the ucm ui in http://127.0.0.1:51060/3tUmMJ859ufqmqBy/ui

Thanks in advance (and thanks for unison)!

[jneira]

Hi, trying to debug the issue i've started adding log output to the estansion with https://github.com/unisonweb/vscode-unison/pull/5 The log was not terrible helpful though:

Language server failed to connect, cause: Error: connect ECONNREFUSED 127.0.0.1:5757

:-/

[jneira]

The ucm executable is listening on the ui port but no on the default lsp port:

PS D:\dev\ws\unison\vscode-unison> Get-Process -Id (Get-NetTCPConnection -LocalPort 60447).OwningProcess

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    257      17    32256      47444       6,63  14512   1 ucm

PS D:\dev\ws\unison\vscode-unison> Get-Process -Id (Get-NetTCPConnection -LocalPort 5757).OwningProcess
Get-NetTCPConnection : No se encontraron objetos MSFT_NetTCPConnection cuya propiedad 'LocalPort' sea igual a '5757'.

[rlmark]

@ChrisPenner @aryairani, as a heads up this seems to be happening for M4d and M4f users as well. I added some labels so it should show up for our next issue triage meeting.

[ChrisPenner]

Ah, yeah, I remember now.

https://github.com/unisonweb/unison/blob/2e0ffc78324732749faf8f7ebc88f888ab524bab/unison-cli/unison/Main.hs#L262-L267

We disabled the LSP on Windows due to a bug in the GHC IO manager for windows that would cause UCM to fail to shut down properly if it was still listening on a port for connections, and unfortunately also made it impossible to kill the thread too.

I think the plan was originally to try again once we got onto a new enough GHC version to use the new IO manager built specifically for windows; but IIRC I think I tried that at one point too and it had the same problem.

All that said, there's probably some other way around this that I could figure out if I spent some more time on it;

Maybe in the mean-time we make LSP on Windows "opt-in" by requiring that the UNISON_LSP_PORT variable be set or something? The only real problem with enabling LSP is that UCM won't quit unless you SIGKILL it, so if people are okay with that as a workaround that could buy us a bit more time 😬

At the very least I should update documentation to reflect the current situation on Windows.

[jneira]

Thanks for the feedback, i navigated the code for a while and i did not find the comment 🤦

Is there some ticket about that ghc bug? It may help to reproduce it and to know if there is some workaround. haskell-language-server itself is listening on tcp ports and afaik does not exhibit the problem in windows when built with ghc.8-* so it would be a good source to comapre and extract the workaround, if it is needed.

The new ghc win io manager is not set by default in 9.2 iirc and not sure about its status in 9.4 but it is previsible it would suffer from bugs until its final stabilization.

Maybe in the mean-time we make LSP on Windows "opt-in" by requiring that the UNISON_LSP_PORT variable be set or something? The only real problem with enabling LSP is that UCM won't quit unless you SIGKILL it, so if people are okay with that as a workaround that could buy us a bit more time 😬

💯 for this, a note in docs with a warning would be great imo

[ChrisPenner]

@jneira I think it may be related to this note from https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1224

There is no deadlock avoidance guarantee. If you block on an IOPort and your Haskell application does not have any work left to do the whole application is stalled. In the threaded RTS we just continue idling, in the non-threaded rts the scheduler is blocked.

But I'd need to look in a bit deeper to know for sure and unfortunately we're quite busy working on other aspects of Share at the moment. Maybe there's a non-blocking operation I can use to read from the socket instead 🤔

[jneira]

I have tested master enabling the lsp server for windows and it started to work fine, however even quiting from ucm shell makes it hangs and it needs a ctrl+c to return to system shell

so not sure if it would be an option...

[ChrisPenner]

Hrmm, yeah that's what I was experiencing too.

The only other thing I can think that would be worth trying would be to compile on a version of GHC that supports the native IO manager on windows (I'm not positive which ones do, but I'd guess 9.2.5 probably does), and run that with +RTS --io-manager=native

And also try to determine whether it's the socket binding or the socket reading that's causing the hanging; then see about replacing that part with something non-blocking: https://github.com/unisonweb/unison/blob/a885d688343681eb3ee2e374c2cdfba213041f7a/unison-cli/src/Unison/LSP.hs#L55

If you happen to have a chance to look into it that'd be fantastic, though I completely understand if that's a bit too much work.

[dolio]

Plan: document current limitations on Windows, and make it opt-in with a caveat.

[jcmrva]

Could a flag be added, like ucm --lsp, so that it only starts when desired (e.g. in VS Code), but if you just want to run ucm in the terminal, it won't hang on close? Or any other reason for not wanting LSP to be running.