I'm surprised there's no issue about this. Apparently I only ever created a Pull Request that I closed for it. So this serves as the tracking issue for the auto splitters.
We are using WebAssembly as the "scripting language" of choice for livesplit-core's auto splitting. We initially were choosing among various Rust and C based scripting languages (see #27) but ultimately decided against any specific one of them due to either immaturity, security or other limitations of those languages. By choosing WebAssembly the auto splitter scripts run in a fully sandboxed environment where they can not escape and we can gracefully shut them down if they either crash or hang. We specify clearly the APIs they can use, unlike the Auto Splitters in the original LiveSplit that had full access to all our internals. In addition WebAssembly allows you to choose any language that you'd like to use for writing your script in, which allows us to have a highly domain specific high level language such as the original ASL again, but also allow for the option of using Rust, C, C++ or any other low level language, which can now even statically link all kinds of helper libraries for full low level control over the memory they are reading from the game's process. Also there's the option of using higher level scripting languages such as TypeScript / JavaScript or Python. So there's a lot of possibilites in this space.
As the library of choice we started out with wasmi (the wasm interpreter), which is fast enough for most use cases, but especially when using Python as the language for implementing the scripts, it begins to show some slowdowns. That's why we are slowly gravitating towards wasmer + cranelift which so far seems to be a great choice for actually compiled wasm code. However there's some issues (such as calling conventions on Windows) that still need to be figured out until we can make the full switch here.
Also so far all of this only compiles on Windows, so some of the process / memory APIs need to be implemented for macOS and Linux as well.
I'm surprised there's no issue about this. Apparently I only ever created a Pull Request that I closed for it. So this serves as the tracking issue for the auto splitters.
We are using WebAssembly as the "scripting language" of choice for livesplit-core's auto splitting. We initially were choosing among various Rust and C based scripting languages (see #27) but ultimately decided against any specific one of them due to either immaturity, security or other limitations of those languages. By choosing WebAssembly the auto splitter scripts run in a fully sandboxed environment where they can not escape and we can gracefully shut them down if they either crash or hang. We specify clearly the APIs they can use, unlike the Auto Splitters in the original LiveSplit that had full access to all our internals. In addition WebAssembly allows you to choose any language that you'd like to use for writing your script in, which allows us to have a highly domain specific high level language such as the original ASL again, but also allow for the option of using Rust, C, C++ or any other low level language, which can now even statically link all kinds of helper libraries for full low level control over the memory they are reading from the game's process. Also there's the option of using higher level scripting languages such as TypeScript / JavaScript or Python. So there's a lot of possibilites in this space.
As the library of choice we started out with wasmi (the wasm interpreter), which is fast enough for most use cases, but especially when using Python as the language for implementing the scripts, it begins to show some slowdowns. That's why we are slowly gravitating towards wasmer + cranelift which so far seems to be a great choice for actually compiled wasm code. However there's some issues (such as calling conventions on Windows) that still need to be figured out until we can make the full switch here.
Also so far all of this only compiles on Windows, so some of the process / memory APIs need to be implemented for macOS and Linux as well.