[emscripten] build with emscripten

[PatrickSpeicher]

We implemented all necessary changes to compile FastDownward with emscripten and run the resulting wasm binary in a browser.
Our work was initially presented at ICPAPS'20. For more details, visit: https://sites.google.com/view/planning-in-the-browser/startseite

We added a README and example files inside src/javavascript/ explaining the process of compiling the project with emscripten and testing it in the browser.

Feel free to contact me via email: [email protected]

[haz]

So fun :D.

Any chance you'd be up for wrapping the invocation to mirror the solver.planning.domains API format? That way, the online editor could be configured to load/use things locally (to the client). Would be mighty helpful for courses using the editor.

[PatrickSpeicher]

@haz Yes, definitely!
I believe this would be a perfect addition for the planning.domains project and I would love to implement this as the next step after our changes to the source code are somewhat approved.

[PatrickSpeicher]

@haz We pushed the necessary changes for running the translator in the browser.
It works by first building the translator as a python wheel and then running it in the browser using Pyodide.
The code for that (incl. Readme and example files) is in src/javascript/translator.

[haz]

Nice! We already have pyodide loading in the editor for tarski parsing, so it's already ready to go.

Have the wrap to mirror the online solver API?

[roeger]

Hi @PatrickSpeicher,

sorry that this took so extraordinarily long for us to look into this.

One major reason why no-one took this up earlier is probably that the emscripten support would have to be maintained in the long term and we do not have the expertise to do so. Also some of the changes (in particular the restructuring of the translate component and the --input parameter) are rather controversial and we would need to work together to explore alternatives.

In the (very) long term, we also plan to join the translator and search component (with a C++ implementation and Python interface), and I don't see that anyone from the team would be interested to do the necessary changes to the emscripten support.

So before we dive deeper into a discussion, three quick questions:

1. Are you still interested in an integration after such a long time?
2. Would you be willing to serve as a maintainer for the emscripten support (also in the long term)?
3. Could it be an option to keep the emscripten support external (just keeping the fork)?

Best,
Gabi