Launching ydoc-server together with language-server

[JaroslavTulach]

Pull Request Description

• Another attempt to fix Start Ydoc with the language server #9862
• @Frizi would like to see ydoc-server running in the enso process
  • Disable Graal-based Ydoc temporarily #10627 had to disable it as it was giving an impression of a slower startup
  • but now the startup of Enso is no longer a problem with native image executable
• thus let's include ydoc-server again in the enso executable
  • but without increasing enso image size
  • e.g. let's use Dual NI + JVM Mode for Loading Libraries #13172 - but not for libraries, but for loading Graal.js and websocket emulation
• by running ydoc-server in the same process we are one step closer to remove Akka networking layer

Checklist & TODO

Inception review has happened on May 28, 2025 and based on that following action items (related to this PR) were identified:

• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.
• (Almost) no increase in enso executable size - done
• Measure startup slow down
  • done - far less than 500ms when built into native image
  • with the current dual JVM mode the startup of the Ydoc server is slower - still less than 2s
  • the idea however is to bring it back below 0.5s by compiling the ydoc-server project into "dual native library"
• Drop ydoc-server-nodejs source code - done
• Drop ydoc-server-nodejs docker image - done - there still is ydoc-server-polyglot docker image, in case we need 1:1 replacement for the docker image
• Add --ydoc-port <number> option to language-server - kinda done by Launching ydoc-server together with language-server #13178 (comment)
• Expand project/open to provide also ydoc-port value
• Change corepack pnpm dev:gui to use this GraalVM based Ydoc server: done
• Ensure .AppImage & co. are OK using the embedded ydoc-server - works since 76a0265
• Ensure cloud is OK using the embedded ydoc-server

[JaroslavTulach]

Snapshot of memory usage of the JavaScript inside of org.enso.runner.Main process:

The Y.doc JavaScript data structures are estimated to fit into 2MB of memory.

[JaroslavTulach]

• there is a significant problem:
  • CI is running out of memory on Linux when building the enso native image
  • CI Windows run is fine - it just fails on the native image post mortem check - it is too big - e.g. 606MB - but we could increase the limit...
  • CI Mac run also fails on GC related problems
• I am afraid we have to suspend this PR until we make the native image smaller
• for example by Dual NI + JVM Mode for Loading Libraries #13172, ach.

Update on Oct 6, 2025

• now this PR actually uses the Dual NI + JVM Mode for Loading Libraries #13172 for running itself
• e.g. the websocket emulation & Graal.js interpreter are executed in dual JVM
• without any impact on the size of the native image

[PabloBuchu]

LGTM. After adjusting exposed port in Dockerfile all should be fixed. Lemme know when its merged and done in nightly so I can test in the cloud

[JaroslavTulach]

• before this change I had to specify the Ydoc port for unpacked AppImage manually:
• enso/dist/ide/linux-unpacked/enso --engine.ydocUrl=http://localhost:5976
• the AppImage connects to internal Ydoc server automatically
• here is a proof internal Ydoc server (with WebSocket emulated via Helidon library) is used

[farmaazon]

The JS part LGTM

[4e6]

@JaroslavTulach I pushed the commit that fixes nightly build and scheduled nigthly release to verify.

[4e6]

The nightly looks fine

[hubertp]

I don't like that we have this hardcoded port copied over and over in multiple places. But it has been there before.

But I do mind the extra logs/print err we seem to add when starting YDoc Server. Approving, but please consider the changes.

[hubertp]

Wouldn't it be just easier to read with a list and check with contains?

[JaroslavTulach]

• consistency among various InteropLibrary messages is subject to may innovation
• alas usually it is subject to clueless evolution (like in this case)
• it starts simple return "addPath".equals(member); and then it gets more and more convoluted
• you'd like a change to

• enso/engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoFile.java

  Line 215 in a20924d

  private static final String[] MEMBERS =

• yeah, that may be better
• anyway consistency among various implementations spread around the code base would remain a problem

[JaroslavTulach]

• @4e6, project-manager tests are failing again https://github.com/enso-org/enso/actions/runs/18456787495/job/52588422347?pr=13178#step:14:6518

 INFO ide_ci::program::command: sbt ℹ️ [error]     org.enso.projectmanager.infrastructure.languageserver.LanguageServerGatewaySpec
 INFO ide_ci::program::command: sbt ℹ️ [error]     org.enso.projectmanager.protocol.ProjectShutdownSpec
 INFO ide_ci::program::command: sbt ℹ️ [error]     org.enso.projectmanager.protocol.ProjectManagementApiSpec

• Given project-manager has been removed in Remove project manager from Electron #14116
• Can we disable these tests in my branch?
• Failed again. Disabled in 6b45001