Scala Metals fails about jupyterlab-lsp HOT 12 CLOSED

Since #92 has been merged, I just tried again using a dev build on master.
I get a fully resolved path under $HOME now and Metals starts up fine! 🎉

Thanks for the fast fix! I guess this issue can be closed now.

from jupyterlab-lsp.

Thank you all for the pointers!
This is how rootUri looks in the init message:

[Trace - 08:11:28 AM] Received request 'initialize - (0)'
Params: {
  "processId": null,
  "rootUri": "file:///~/tmp/jupyterlab-lsp",
  ...

I tried starting jupyter lab from somewhere outside $HOME as suggested by @bollwyvl and it seems Metals is starting up normally. I can see it creating its startup files, there's LSP communication in lsp.trace.json, and the status bar says "fully initialized.

We still don't get back anything really usable as most answers are empty.

[Trace - 06:58:41 PM] Sending notification 'textDocument/publishDiagnostics'
Params: {
  "uri": "file:///private/tmp/jupyter-lsp/scala.ipynb",
  "diagnostics": []
}

But I assume that's because Metals doesn't support Scala script files yet and has nothing to do with jupyterlab-lsp.

So I guess fully resolving rootPath on the server (#91) should solve the issue here.

from jupyterlab-lsp.

What happens if you enable LSP tracing? It looks like the workspace rootUri provided in the “initialize” request is the root directory “/“, I would expect it to be a directory containing only the source code of the Jupyter notebooks.

from jupyterlab-lsp.

Hi there, thank you @mardukbp for reporting the issue and thanks @olafurpg for chiming in. Two quick notes:

• the JupyterLab does not expose the full path of the file in the server to the frontend extensions so it has to be passed around as a relative path, but the server proxy (jsonrpc-ws-proxy/dist/server.js) does not play well with it, even if started from the same directory.
  I was experimenting with different rootUris as a workaround, nothing seems to work (and therefore rootUri may look strange).
• for that reason (but not only) the future versions of jupyterlab-lsp will be using a different approach as outlined in #2 (instead of javascript-based jsonrpc-ws-proxy).

from jupyterlab-lsp.

Would it be possible to create a temporary directory to host the workspace rootUri? Metals should work fine if the file contents is passed via text synchronization. We need the ability to create files/directories in the workspace to host logs and a small SQL database under .metals/.

from jupyterlab-lsp.

Metals may crash on relative URIs since we generally assume file URIs are absolute. Another situation where we assume a file system is library dependency sources, which we write to the .metals/readonly/ directory when users run "goto definition" on an external symbol.

from jupyterlab-lsp.

I just gave this another shot with 0.6 and I think we're getting closer, as rootUri contains the path now.

INFO  logging to file /~/tmp/jupyterlab-lsp/.metals/metals.log
Nov 03, 2019 12:18:18 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError
SEVERE: Internal error: java.nio.file.FileSystemException: /~: Read-only file system

Unfortunately starting the path with /~ still causes issues. I assume the ~ is supposed to be resolved to $HOME at some point. Any ideas where it originates from?

from jupyterlab-lsp.

Yeah, the history of why the ~ even shows up is a bit odd: it's mostly cosmetic for a particular dialog in notebook classic, but is pretty painful in the language server context.

At any rate, if you fired it up from basically anywhere other than your home directory, it might work as-is. We should add an un-mangled, case normalized (because windows drive letters) canonical rootUri to the (as-yet unreleased, #81 and #90) server route which lists the servers.

One thing that would help would be digging into the actual websocket messages in the network tab of the browser to see what the contents of the initialization message actually is.

from jupyterlab-lsp.

To listen to incoming/outgoing JSON communication you can create the following file and restart Metals

~/Library/Caches/org.scalameta.metals/lsp.trace.json

from jupyterlab-lsp.

Probably related (but not 100% sure):

https://github.com/krassowski/jupyterlab-lsp/blob/92d2833c28632a7e66102ff597063b5ff68b92c8/packages/jupyterlab-lsp/src/index.ts#L73-L89

I think we need to resolve the root path in jupyter-lsp and get it with REST-like /lsp endpoint instead...

from jupyterlab-lsp.

Thank you so much for continuing to fight with this! ⚔️ 🛡️

Metals doesn't support Scala script files yet

Yeah, we'll need to be able to generate virtual files for ipynb.scala (or whatever). this is where breaking up, normalizing, and handling per-language client features (#76 step 3) will come into play. This is as good an issue as any to start discussing it, but there's still a lot of work to do.

from jupyterlab-lsp.

Hello everyone :)

regarding:

Metals doesn't support Scala script files yet

Do you think it is possible to "fallback" in Ammonite as it happens in VS?
If not it seams to me useless to even add Scala LSP.

from jupyterlab-lsp.