Skip to content

Webworker proposal for running Source programs

Martin Henz edited this page Dec 18, 2021 · 1 revision

TL;DR

https://source.openorclo.se/

I (Daryl) created a barebones "transpiler" here. Currently you have to manually transpile your code (:.

Most importantly, you can try running the "infinite" preset. Note that it doesn't hang the browser since the code runs on a separate thread, and a second later the output is returned.

I have the setglobal and getglobal preset just as a proof of concept that we can save/retrieve variables.


Motivations

Hanging the browser, no matter how short a period of time, makes for a horrible user experience. We should try and solve this.

Even in the interpreter, builtins still cause these hangings sometimes.

Ultimately, it would be great if we can move the interpreter and native evaller out into a web worker.


Limitations

  • Functions cannot be passed to and from WebWorkers. Which is just as well, since we need a new library loading mechanism anyway, and if we decide to pass in libraries as strings and then (eval them in native) / (interpret them in the interpreter) this becomes a non-issue.
  • Webworkers do not allow interop with the DOM. show, display etc all require the dom. Potentially, we can create a wrapper that returns some intermediate value, and then call the real show or display function in the main thread.
  • Non-primitives that are passed to/from workers are copied (example: give an object {a:1} to a worker and let the worker return the same thing then compare them with ===, it evaluates to false) , and furthermore as mentioned functions cannot be passed back into the main thread. This means that any updating of the context (saving global variables etc) needs to be done on the worker thread itself, and it is impossible to gain knowledge about it from the main thread. Therefore, If debugger/inspector requires non-JSON-stringifiable information it would not be possible to get it using this method.
  • Obviously, it would be horrible to try to write tests and test it in this repo, and I'm unsure if it can be solely done in cadet-frontend. If not, there would be very tight coupling between the two repos, which is undesirable.

Conclusion

CP3108?