FR: provide OCamlPro.SuperBOL-mini

[GitMensch]

OCamlPro.SuperBOL is nice and commonly usable.
It likely has some issues with vscode-web (see also #188), but even with a WASM server (which seems to be a long shot) it may not work in "minimal environments".

I'm currently having fun in a minimal reh environment where the remote extension host does not work.
At least in cases like this an OCamlPro.SuperBOL-mini would be nice to have a version that has no need to run there (=local editor). This would likely mean:

• no native LSP interaction
• using only the open editor window(s)

Can you provide an extension like this (=taking this one and deleting all parts that would need to run "wherever the code is", reducing it to the local editor? ... maybe solve #193 first as that is implicit about "using the editor window instead of files"...

This would mean at least:

• minimal syntax highlighting
• problem matchers
• un/comment line/block
• possibly snippets
• possibly "go to definition" using regex (= no REPLACE/COPY support)

[nberth]

Putting #193 aside temporarily (might be easier to fix than it looks).

I reckon we have not dug enough after #93 reached its current status (and indeed the WebAssembly solution does not seem very approachable at the moment). Yet, I think there's still a path forward available to provide a more lightweight "universal" extension via a JS-only extension. What we observed in #93 was:

1. compiling the LSP server to JS was straightforward;
2. the JS-based server suffered from stack overflows (at least when computing semantic tokens — we don't know whether other features caused this);
3. the alternative compilation scheme (using effects) seemed to solve the above stack overflow issue, but also led to poor performances.

Reviewing that code again, I observe an external node executable was used to interpret the JS-based server. As noted in a comment using the interpreter that ships with VSCode might be preferable (as exemplified in Language Server Extension Guide , where the server is actually compiled from TS to JS).
So, instead of manually stripping the extension and re-implement approximate feratures, I suggest we could pursue our investigations towards a JS-based server that would operate in "degraded" mode when it is compiled to JS:

1. It might be worth trying the VSCode-provided interpreter first, to see if it still suffers from the same issues as a native node;
2. If the above is still not workable, then detecting that the server is in JS first — I guess there's a way to do that via Sys.backend_type (or optionally via a --degraded-mode CLI flag, set by the extension), and then not fulfilling every requested server capabilities in Lsp_capabilities.reply (at first, disabling semantic tokens, then maybe some others);
3. Still try the alternative compilation scheme after this, to reduce likelihood of stack overflows at runtime;
4. Check whether there's a way to force the LSP client to batch or de-throttle its "document change" notifications.

If that succeeds, we'd likely get an operational universal extension without much effort on the (non-LSP server) extension side.

[GitMensch]

1 is definitely reasonable, the rest sounds good as well.
One of the biggest issues for 1 is also to have a working node binary at all (think for example about glibc-217, musl, bionic).

... but that belongs more to #188, this one is really about a minimal version that runs on vscode in the client parts (the view) alone - without any "vscode server" side - I think any LSP will be a server-side issue (at least if it operates on more that the current opened editor windows).

The "last piece" of the need for the request of an additional "most downgraded" one is not rooted in the web-frontends (but even there a minimal version which would have a much reduced memory and cpu footprint would be useful) but in a bionic environment where I have a working REH with a system-provided node version. Opening files work, but nearly any extension that is "server side" crashes because of missing glibc. Only "client" extensions work fine.

[nberth]

The "last piece" of the need for the request of an additional "most downgraded" one is not rooted in the web-frontends (but even there a minimal version which would have a much reduced memory and cpu footprint would be useful) but in a bionic environment where I have a working REH with a system-provided node version. Opening files work, but nearly any extension that is "server side" crashes because of missing glibc. Only "client" extensions work fine.

At the moment SuperBOL is a "workspace" extension (instead of a "UI" one that always runs "locally").

According to this documentation, providing a purely JS extension may work. Does this REH runs a VSCode server or something similar?

[GitMensch]

At the moment SuperBOL is a "workspace" extension (instead of a "UI" one that always runs "locally").

and I think that's good; therefore the request for a trimmed-down version with minor adjustments to a separate UI only one (which may or may not be built from the same source tree)

Does this REH runs a VSCode server or something similar?

yes, REH = code-server/codium-server/... which runs a node executable on a different host

[emilienlemaire]

Hi Simon, could you please check the last commit on #93, and build the extension with make all-vsix-package TARGET_PLATFORMS=web and try it on your REH?

[GitMensch]

Should be possible... in several days (I don't have this checked out or necessary tools installed and there's no gitpod.yml or GH codespace definition for "direct dive into" either).

Please just execute those commands and upload the .vsix here (attaching a .zip, what a .vsix is after renaming should be fine), thius way I could have a quick look "soon". (and of course, #113 would help here as well)

[emilienlemaire]

The file is too large to be uploaded here, I'll send it by email to you :)

[GitMensch]

Uninstalled the previous version, then restarted VSC, then installed the one sent by mail.

"locally" it runs, from Language Server Output:

SuperBOL, by OCamlPro. https://get-superbol.com. Affero GPL version.
[Info  - 5:17:18 PM] Initializing for workspace folders: 
[Info  - 5:17:19 PM] Negociated server parameters:
{ client_config_watcher: true
  client_file_watcher: true }
[Info  - 5:17:19 PM] Failed to read cache: .\_superbol\lsp-cache: No such file or directory
[Info  - 5:17:19 PM] Received client configuration: [ { "dialect": "default", "source-format": "auto", "copybooks": [ { "dir": "." } ] } ]
[Info  - 5:17:25 PM] Getting configuration for project of untitled:Untitled-5
Reply: { "cobol.dialect": "default", "cobol.source-format": "auto", "cobol.copybooks": [ { "dir": "." } ] }

Using REH does not work on all (just connected to a normally working Debian machine):

[Error - 17:16:28] SuperBOL Language Server client: couldn't create connection to server.
Launching server using command superbol-free failed. Error: spawn superbol-free EACCES

In that second environment there are no commands like "show references", but words are highlighted including hyphens, in the first environment (locally) those commands exist but don't yield any result, words are split at the hyphen.

[nberth]

In that second environment there are no commands like "show references", but words are highlighted including hyphens,

@emilienlemaire likely an issue in lookup of LSP server executable;

in the first environment (locally) those commands exist but don't yield any result, words are split at the hyphen.

My guess here is that's more likely linked to #193.

Now we know what kind of investigations the new year will start with ;)

[GitMensch]

Wasn't the whole point of this "web" version that there shouldn't be a separate LSP server executable?!?

[nberth]

Wasn't the whole point of this "web" version that there shouldn't be a separate LSP server executable?!?

No, in this "web" version the server executable is just OCaml compiled into JS (so it can run anywhere JS can run). Makes me think, a possible cause for the error is that you have a non-empty setting for superbol.lsp-path. Otherwise, if as indicated above there's an issue in the extension code that does the lookup, maybe removing any file named _dist/superbol-free within the extension's installation folder (or the VSIX archive (zip) itself) would temporarily lead to better results.

[GitMensch]

There's only superbol-free.js in there.

I did a dirty hack of adding a script there

#!/usr/bin/env sh
$HOME/.vscodium-server/bin/aeb27bab9c36227d2180b3b25c5b11423aafb976/node $(dirname "$0")/"superbol-free.js" "$@"

leading to the "binary" be found and executed, but only outputting

SuperBOL, by OCamlPro. https://get-superbol.com. Affero GPL version.
fatal exception TypeError: runtime.unix_getpid is not a function

[Info  - 21:25:49] Connection to server got closed. Server will restart.
[Error - 21:25:49] Server initialization failed.
  Message: Pending response rejected since connection got disposed
  Code: -32097 
[Error - 21:25:49] SuperBOL Language Server client: couldn't create connection to server.
  Message: Pending response rejected since connection got disposed
  Code: -32097 

... but the issue seems that the superbol-free "binary" is tried to be executed, while instead the node binary should be executed with a parameter to that script. [warning: I have no clue, just guessing around]