Can't connect via TCP

[Sainan]

I'm trying to use the Pluto Language Server with the following configuration:

[lspservers.lua]
mode = "tpc"
executable = 'C:\Windows\System32\PING.EXE'
args = ''
auto_start_server = false
port = 9170
host = "127.0.0.1"

The server is running fine, but the logs seem to indicate that the client attempts to write to an un-opened socket(?)

I know it's not a broken pipe because the language server would've logged any connection events, and the plugin would've probably thrown "ERROR: attempt to write to non-existent pipe".

[Ekopalypse]

Thanks for your interest. Just tested it with Npp 8.5.2 and the latest version of NppLspClient and it seems to work with tcp when I use python.

Did you restart Npp after configuring the server? Or executed "apply current configuration" from the lsp client plugin menu? I am not familiar with pluto ls. Can you give me a small script and describe what I need to do to set it up so I can test it?

[Ekopalypse]

I was able to start and communicate with the server.

[Ekopalypse]

Seems the pluto ls is terminating the session

[Sainan]

I did use "apply current configuration".

In my example I explicitly asked the NppLspClient to launch PING.EXE but still connect to localhost at port 9170 so I could monitor the standard output of the Pluto language server for connection events.

Although even when I don't do that, it doesn't seem able to communicate (same "writing to socket failed" in NppLspClient's console)

This might be because there ought to be a delay between starting the language server and attempting to connect to it. I don't think that's a language server problem, because it should bind the port as soon as the scheduler gives it a chance to run.

[Ekopalypse]

I re-downloaded everything today, because I'm running the test within a sandbox, and was able to communicate with the server using cmd.exe (instead of ping.exe) as the fake pluto ls.

but at some point it got disconnected as you see in the screenshot.

BUT there is a problem when using pluto ls directly, but to be honest I don't understand why as it is still tcp from a communication standpoint.

There is an initial communication, the client sends the initialization request, the server responds and then some other messages are sent by the client until the connection is broken.

[Sainan]

Yeah, it seems for you it disconnects after a C++ exception is thrown.

But for me the issue is that I can't get it to connect via TCP at all. Even using CMD.EXE (so the dummy subprocess stays alive), it just fails like so:

I am using the latest release build (v0.0.13-alpha), maybe you already fixed it since then.

[Ekopalypse]

No, I am using the latest public version when testing as well. Hmm, that's strange. How do you test, what operating system and npp version?

[Sainan]

Notepad++ v8.5.2 on Windows 10. 64-bit version of N++ & the plugin.

[Ekopalypse]

That is the same as I have.

[Sainan]

That's strange. Idk, must be something about my machine, then. Not a huge issue since I can use the tcp over stdio proxy and that works fine.

[Ekopalypse]

Do you or did you get this usual allow prorgam x to open a port message? Maybe a firewall issue

[Sainan]

Turned off firewall, still same issue.

I do use a VPN, tho (Mullvad), but same issue with Wireguard and OpenVPN protocols, and when I turn it off.

[Ekopalypse]

I'm running out of ideas and on the verge of doing something private. I'll check back later, if you think of anything else you want me to test, feel free to let me know, I'm interested in making it work.

[Ekopalypse]

It looks like your problem of having no communication at all is due to the misspelled tpc vs tcp entry. I can replicate your behavior if I configure it that way as well.

Reopening, as this MUST be catched by the npplspclient.

[Ekopalypse]

from version v.0.0.30 tcp support is available