Sören Brunk

Thanks for confirming @novakov-alexey. I ended up using the workaround to split into several exec calls for now as you've also suggested.

Respecting container RAM limits has been backported to Java 8 as well. Since update 131 or so, it works if you add the the `-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap` JVM args. You should...

I had a quick look into what could be done to support `JAVA_OPTS`. Wrapping the launcher in a shell script seems to work. By replacing `$(jupyter --data-dir)/kernels/scala/kernel.json` with the following...

Realizing that coursier creates a launcher.jar containing [a shell preamble (or a launcher.bat along the launcher on windows)](https://get-coursier.io/docs/cli-bootstrap.html#windows), I guess we could also generate a kernel.json that executes the launcher.jar/launcher.bat...

Ah great that makes sense. That way we can still keep things nicely separated but sync versions automatically. I just didn't think about submodules and that we can push into...

One more remark for validation: By default, nbconvert stops executing the remaining cells as soon as it encounters an error i.e. compilaton failure or an exception. This usually makes sense...

I guess supporting only the latest two major Scala versions is quite reasonable given that Ammonite does the same.

@YannMoisan with almond `0.7.0` out, does it work for you now?

One way to find out the version is from a running notebook. In the menu bar select Help -> About (About the Scala Kernel in JupyterLab): 

Yeah too bad the vscode Jupyter support is still limited to python. :( Seems like the minimal tweaking needs to be done in [variableinspector.ts](https://github.com/lckr/jupyterlab-variableInspector/blob/7a284978a2654bf937078ece8172da453f65f816/src/inspectorscripts.ts#L4-L8) by providing a `LanguageModel ` for...