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

Allowing remote LSP connection in vscode API #102

Merged
merged 15 commits into from
Sep 6, 2024

Conversation

Stevendeo
Copy link
Contributor

This PR adds the required utils for connecting vscode editor to a remote LSP.

@nberth
Copy link
Collaborator

nberth commented Oct 30, 2023

@Stevendeo we you say "remote", do you mean the LSP has no longer access to the file-system where the project source code is? If that's the case, I think quite a bit of work is needed, and we should schedule for a much later milestone.

In particular, we should first handle some of the workspace-related requests.

@Stevendeo
Copy link
Contributor Author

@Stevendeo we you say "remote", do you mean the LSP has no longer access to the file-system where the project source code is? If that's the case, I think quite a bit of work is needed, and we should schedule for a much later milestone.

In particular, we should first handle some of the workspace-related requests.

We discussed this particular issue with Fabrice the other day, so I was making a few tests. This PR is still in draft and should not have impact on the project anyway.

@Stevendeo
Copy link
Contributor Author

@Stevendeo we you say "remote", do you mean the LSP has no longer access to the file-system where the project source code is? If that's the case, I think quite a bit of work is needed, and we should schedule for a much later milestone.

In particular, we should first handle some of the workspace-related requests.

Oh, and no I am just talking about the lsp being accessible through a specific address & port. I think this step is necessary before having the whole project in remote.

Copy link
Collaborator

@nberth nberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok now I start seeing what development with jsoo looks like ;-)

Very minor comments to address, and we can merge.

@Stevendeo
Copy link
Contributor Author

Ok now I start seeing what development with jsoo looks like ;-)

To be fair, it should and could probably be cleaner. The problem is here that I did not find the interface between js of ocaml and the library used in the project, nor a module for websockets. I'm pretty sure there is one, but for testing I don't need it and I can do dirty things (until it breaks, because it will).

Copy link
Collaborator

@nberth nberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok to merge. BTW do you just test it with nc?

@Stevendeo
Copy link
Contributor Author

Stevendeo commented Nov 15, 2023

I did not test it yet, I did not manage to find the proper combination to make it work, as superbol expects to receive something directly from stdin and not as an argument. Is there a way to call something like superbol-free lsp file.json ?

EDIT: nevermind, by writing this message I found how to.

@Stevendeo
Copy link
Contributor Author

Okay, so it manages to establish a connection, but I think something is wrong when actually sending the data.

@Stevendeo
Copy link
Contributor Author

I added a script to simulate a remote LSP in local. For now it only allows to receive data and give it to the LSP, which seems
to have some trouble to decode the request.

@Stevendeo Stevendeo changed the title Allowing remote LSP for superbol Allowing remote LSP connection in vscode API Nov 15, 2023
REMOTE_TEST.md Outdated
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could just

mkfifo /tmp/somewhere # possibly in a directory resulting from `mktemp -d`
nc -l 8000 < /tmp/somewhere | superbol-free lsp > /tmp/somewhere

(as suggested here)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely can't make nc work properly with the lsp server... I'll try something else I spend too much time on that

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the protocol used is HTTP/1.1 with chunk transfer encoding, which I believe is not handled by the current lsp server...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean the websocket layer uses that protocol?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, perhaps that is the protocol used by VSCode when communicating through a remote server.

Copy link
Collaborator

@nberth nberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the REMOTE_TEST.md still needs some changes. Also, I think for the moment its contents would better fit in the sphinx docs, maybe in a new file sphinx/remote-lsp.rst.

@GitMensch
Copy link

So this "just" needs a move + adjustment of the docs + rebase to be merged?

@Stevendego
Copy link

Doc updated & branch rebased!

Copy link
Collaborator

@nberth nberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see that revived ;-)

I think there's a point remaining about the documentation for testing that feature.

Comment on lines 52 to 54
LanguageClient.make_stream
~id
~name
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
LanguageClient.make_stream
~id
~name
LanguageClient.make_stream ~id ~name

Comment on lines 59 to 65
Promise.return (
Vscode_languageclient.StreamInfo.create
~writer:njs_stream
~reader:njs_stream
()
)
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Promise.return (
Vscode_languageclient.StreamInfo.create
~writer:njs_stream
~reader:njs_stream
()
)
)
Promise.return @@
Vscode_languageclient.StreamInfo.create ()
~writer:njs_stream
~reader:njs_stream)

Comment on lines 68 to 72
LanguageClient.make ()
~id
~name
~serverOptions
~clientOptions
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
LanguageClient.make ()
~id
~name
~serverOptions
~clientOptions
LanguageClient.make () ~id ~name ~serverOptions ~clientOptions

(We don't go that vertical in this project.)

~clientOptions:(Superbol_languageclient.client_options ())
let cmd = Executable.command serverOptions in
if String.starts_with ~prefix:"ws://" cmd then
LanguageClient.make_stream
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I right if I observe that options given to "usual" servers are ignored?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what is the string that needs to be put in the command for testing? Is it just something like ws://localhost:<some port>?

Copy link

@Stevendego Stevendego Aug 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This PR is a bit old even for me, I'll try to answer as I remeber)

Am I right if I observe that options given to "usual" servers are ignored?

For now yes, I just added the bare minimum.

what is the string that needs to be put in the command for testing

ws:// is the prefix to add to the VSCode URL in its configuration. For testing with the cmd, just start the lsp and use this command

and call it with `test.nc`.

TODO: this script only receives information, but does not send it back to
VSCODE; it only writes it in superbol.log. It should answer to the client.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's quite a big TODO. What happens when you try this suggestion?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's quite a big TODO.

The thing was, when I started this PR, the LSP did not have a HTTP server (compatible with VSCode) , hence neither these script actually make it work. This PR was initially only to provide the base before starting the actual server

import/merlin Outdated Show resolved Hide resolved
@Stevendego
Copy link

Stevendego commented Aug 23, 2024

I'd say there is a missing dependency somewhere, I don't have any error

EDIT : $ npm install ws?

@nberth
Copy link
Collaborator

nberth commented Aug 23, 2024

I'd say there is a missing dependency somewhere, I don't have any error

EDIT : $ npm install ws?

Yes I think that should be a dependency to declare in package.json. This file is actually generated from data in src/lsp/superbol_free_lib/vscode_extension.ml. I would add something like "ws", "^8" in the ~dependencies list there.

Edit: What version of ws do you have?

@Stevendego
Copy link

What version of ws do you have?

[email protected] (probably not the latest version, I did not update anything since a looooong time)

@nberth
Copy link
Collaborator

nberth commented Aug 23, 2024

Ok thanks. Note, though: you need to make package.json and then amend the last commit with the generated package.json (the CI checks the generated file does not differ from the package.json in the commit).

@nberth
Copy link
Collaborator

nberth commented Aug 23, 2024

Ouch…

[Error - 4:51:07 PM] SuperBOL Language Server client: couldn't create connection to server.
ReferenceError: joo_global_object is not defined
	at eval (eval at caml_js_eval_string (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:24526:16), <anonymous>:1:1)
	at caml_js_eval_string (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:24526:16)
	at caml_call1 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:44842:57)
	at k$0 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:46114:18)
	at caml_call1 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:38481:57)
	at make_printf$0 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:40953:20)
	at make_printf (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:41330:33)
	at width (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:40934:20)
	at caml_call_gen (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:23284:20)
	at Object.caml_call_gen (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:23289:18)
	at caml_call3 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:54533:81)
	at njs_stream_of_string (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:54833:16)
	at caml_call1 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:57328:57)
	at _t_ (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:57363:32)
	at caml_call1 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:54527:57)
	at /tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:54881:23
	at caml_call_gen (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:23284:20)
	at /tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:28257:18
	at LanguageClient.createMessageTransports (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:17297:18)
	at LanguageClient.<anonymous> (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:15499:41)
	at Generator.next (<anonymous>)
	at /tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:61:61
	at new Promise (<anonymous>)
	at __async (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:45:10)
	at LanguageClient.createConnection (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:15492:16)
	at LanguageClient.<anonymous> (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:15083:43)
	at Generator.next (<anonymous>)
	at /tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:61:61
	at new Promise (<anonymous>)
	at __async (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:45:10)
	at LanguageClient.start (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:15051:16)
	at start (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:54891:48)
	at caml_call1 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:57328:57)
	at _r_ (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:57380:21)
	at caml_call1 (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:47696:57)
	at fulfilled_safe (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:47728:18)
	at caml_call_gen (/tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:23284:20)
	at /tmp/vscode-exts/ocamlpro.superbol-0.1.4/_dist/superbol-vscode-platform-bundle.js:25313:21

@GitMensch
Copy link

@nberth Is there anything missing apart from the Changelog entry?
Would it be reasonable to pull that in soon?

@nberth
Copy link
Collaborator

nberth commented Sep 2, 2024

@nberth Is there anything missing apart from the Changelog entry? Would it be reasonable to pull that in soon?

I think a better error reporting might be relevant still. At the moment if the TCP connection fails VSCode reports a lot of errors to the user, none of which seeming to indicate the root cause of the issue. Fixing that may be delayed though, as otherwise remote connection over TCP is operational (a more secure option, e.g with TLS, could be better — but that's definitely for later).

@Stevendeo I think parts of the new code is not in the proper module. I have a commit ready to move it (did it when I tried to fix error reporting … to no avail alas) ; may I push directly on your branch?

@Stevendeo
Copy link
Contributor Author

Stevendeo commented Sep 2, 2024

may I push directly on your branch?

Yes of course; tell me when you're done so I can push a few last updates (Changelog + doc)

@nberth
Copy link
Collaborator

nberth commented Sep 2, 2024

may I push directly on your branch?

Yes of course; tell me when you're done so I can push a few last updates (Changelog + doc)

Actually I opened a PR on your repository so you can see the changes first.

Some additions for the remote LSP connection
sphinx/remote-lsp.rst Outdated Show resolved Hide resolved
Copy link
Collaborator

@nberth nberth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great many thanks! We can merge after the forgotten comment has been removed.

@Stevendeo
Copy link
Contributor Author

We can merge after the forgotten comment has been removed.

Done and ready to merge!

@nberth nberth merged commit ed344b4 into OCamlPro:master Sep 6, 2024
4 checks passed
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

Successfully merging this pull request may close these issues.

4 participants