Doubts regarding running clang-repl in browser (using jupyterlite)

[anutosh491]

This is a continuation of my work involving llvm and emscripten.
I recently got clang-repl working in the browser through llvm 19.1.5

Here is most of the discussion I had with @sbc100 (#22863)

I can get stuff working now

Except this one error that I see in the console

As y'all can see I can still run stuff with this error

[anutosh491]

So as suggested I add -sEXPORTED_RUNTIME_METHODS=ERRNO_CODES but this is where the problem starts

The network section was showing that there is a problem coming up while looking up for temporary files in the parent folder "/"

[anutosh491]

The temporary files for running clang-repl in the browser are generated here(https://github.com/llvm/llvm-project/blob/eb812d28f542bf0de54c157a7391e446739570cc/clang/lib/Interpreter/Wasm.cpp#L79-L80)

Something like this

  std::string ObjectFileName = PTU.TheModule->getName().str() + ".o";
  std::string BinaryFileName = PTU.TheModule->getName().str() + ".wasm";

As the files concerned (wasm.h and wasm.cpp) are only included in the build against emscripten and play a major role only for running clang-repl in the browser (which is done through emscripten) , I thought that shifting the files to the "tmp" folder provided by emscripten by default would do the trick !

And that did it for me and I don't see anymore Aborted Runtime errors

std::string ObjectFileName = "/tmp/" + PTU.TheModule->getName().str() + ".o";
std::string BinaryFileName = /tmp/" + PTU.TheModule->getName().str() + ".wasm";

[anutosh491]

My question to @sbc100 and anyone interested is that I am curious if what I am doing is hacky/dirty ? as in should we not hardcore "/tmp/" this way ? (only reason I used it while building llvm against emscripten is because it is being provided by default)

I also got suggested that I could do the following

1. create a file system maybe using llvm:vfs while creating an interpreter
2. And everytime we have a temporary file (through the addModule func) we add it there

But won't this interfere/collide with Emscripten's approach to handle file systems ?

[sbc100]

What emscripten filesystem are you using? It looks like you are using one that is backed by the server? Some kind of fetch-based FS?

For temporary/local files you probably don't want to invovle the server so using MEMFS (assuming that is what is in /tmp) makes total sense for those file.

And alternative to explictly adding /tmp would be to change directory into /tmp and run everything from there. e.g. do chdir("/tmp"). This way files won't be created in the root directory by default.

[anutosh491]

And alternative to explictly adding /tmp would be to change directory into /tmp and run everything from there. e.g. do chdir("/tmp"). This way files won't be created in the root directory by default.

Thanks I think this helps me resolve my issues in a way !

[martinRenou]

Hello there! Thanks for the amazing work to get xeus-cpp on emscripten-forge!

What emscripten filesystem are you using? It looks like you are using one that is backed by the server? Some kind of fetch-based FS?

Yes kind-of, except it's an in-browser server proxy. But it acts as if files were coming from a normal Jupyter server.

For temporary/local files you probably don't want to invovle the server so using MEMFS (assuming that is what is in /tmp) makes total sense for those file.

Totally agreed 👍🏽

And alternative to explictly adding /tmp would be to change directory into /tmp and run everything from there. e.g. do chdir("/tmp"). This way files won't be created in the root directory by default.

Does it mean that if the user creates a file with:

#include <iostream>
#include <fstream>  

std::ofstream outfile ("userfile.txt");

outfile << "custom user file!" << std::endl;

outfile.close();

It will be created under /tmp?

In JupyterLite we have everything set in place to correctly change directory to the expected directory (where the notebook lives is where the code runs), and local directory is synchronized with Jupyter content. I feel like having xeus-cpp change directory under the hood would break this behavior.

My suggestion would be to create those temporary run files under /tmp and use them from there, but leave the cwd untouched.

EDIT: For more context. In current JupyterLite, the /tmp directory would be using MEMFS, and the cwd would be using our custom Emscripten FS communicating with the "server".