superbol-studio-oss

superbol-studio-oss copied to clipboard

Performance issues with the Javascript+effects version seem to be too hard to deal with at the moment. Another way towards a "pure" web extension could be to compile the LSP server into WASM using wasm_of_ocaml (or another such compiler).

Originally posted by @nberth in https://github.com/OCamlPro/superbol-studio-oss/issues/93#issuecomment-1978811949

Wouldn't that also allow to provide a universal version (= one that works on all of Windows/Linux/Web)?

Wouldn't that also allow to provide a universal version (= one that works on all of Windows/Linux/Web)?

I would assume so. Yet, this is low priority until we have "external" demands: at the moment it requires some work in wasm_of_ocaml.

Edit: Another way would be to use wasocaml, but we have not tried it either.

There's now a CI version called "web" - is this planned for the web (as hinted by the vsix name) or is this more a "universal" issue (as hinted by the commit messages)?

For a Web version the superbol build/debug commands should be disabled, as there's no way to execute cobc (if you can't get a wasm version of cobc, which will be hard on the GMP dependency (and likely would need a conditional compile to internally use a 128bit type or double 64bit structure - patches welcome :-)).

There's now a CI version called "web" - is this planned for the web (as hinted by the vsix name) or is this more a "universal" issue (as hinted by the commit messages)?

Yes that's for the web, with an LSP server compiled into JavaScript. For now that's more a proof-of-concept, to check that works "properly" (and what features need to be disabled to avoid some issues with the JavaScript interpreter), and how to fune-tune the OCaml->JavaScript transpilation. I'm testing that "web" extension with code-server inside a docker for now; so let's say, "ideal" conditions. More thorough "usability" tests will need a proper remote and an actual codebase (even though I use the large NIST COBOL85 test files).

After that further work will be needed to disable some commands that involve cobc, indeed.

(The commit message may need to be reworded a little, then.)

EDIT: actually, re-reading your message, maybe the answer is the extension is "universal" instead of "web" (as universal may imply web, I guess — or maybe the extension artifact needs to be names "universal" instead?).

For a Web version the superbol build/debug commands should be disabled, as there's no way to execute cobc (if you can't get a wasm version of cobc, which will be hard on the GMP dependency (and likely would need a conditional compile to internally use a 128bit type or double 64bit structure - patches welcome :-)).

That's a very good idea indeed. We are not going the WebAssembly route for the extension for now, but that's definitely something to consider in order to try cobc out even with web extensions.

There's now a CI version called "web" - is this planned for the web (as hinted by the vsix name) or is this more a "universal" issue (as hinted by the commit messages)?

Here's more a informed reply, after I realized I confused several aspects in my previous comment above.

Now that I've read more on the topic, I acknowledge that providing a "web" extension (that would work in vscode.dev, for instance) requires stripping any file-system related operation from the LSP server's code (from my preliminary tests, removing those from the JS seems required, just not "executing" them is not enough). Unfortunately that's not something we can do easily.

However, what's been achieved in #93 are the steps towards a universal "remote" extension, where the extension should run (relatively) fine when hosted on a code-server (whatever glibc and co.). The artifacts could be named "universal", with the understanding that it's for any architecture (but native versions should be preferred)… not sure that conveys the proper message, though.

I think that "universal" can be understood, after all that's every extension which is not platform specific https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions (and obviously there's also a "web platform").

And that's also how open-vsx publishes that:

Works With Linux x64, Windows x64, macOS Intel, Alpine Linux 64 bit, macOS Apple Silicon, Universal

(yes. that extension doesn't work on pure web)