2664b1eb62
During #425, @neilalexander gave constructive feedback that the API is both moving fast, and not good enough yet. This attempts to reduce the incidental complexity at the cost of a little conflation. ### odd presence of `wasm` and `wasi` packages -> `api` package We had public API packages in wasm and wasi, which helped us avoid leaking too many internals as public. That these had names that look like there should be implementations in them cause unnecessary confusion. This squashes both into one package "api" which has no package collission with anything. We've long struggled with the poorly specified and non-uniformly implemented WASI specification. Trying to bring visibility to its constraints knowing they are routinely invalid taints our API for no good reason. This removes all `WASI` commands for a default to invoke the function `_start` if it exists. In doing so, there's only one path to start a module. Moreover, this puts all wasi code in a top-level package "wasi" as it isn't re-imported by any internal types. ### Reuse of Module for pre and post instantiation to `Binary` -> `Module` Module is defined by WebAssembly in many phases, from decoded to instantiated. However, using the same noun in multiple packages is very confusing. We at one point tried a name "DecodedModule" or "InstantiatedModule", but this is a fools errand. By deviating slightly from the spec we can make it unambiguous what a module is. This make a result of compilation a `Binary`, retaining `Module` for an instantiated one. In doing so, there's no longer any name conflicts whatsoever. ### Confusion about config -> `ModuleConfig` Also caused by splitting wasm into wasm+wasi is configuration. This conflates both into the same type `ModuleConfig` as it is simpler than trying to explain a "will never be finished" api of wasi snapshot-01 in routine use of WebAssembly. In other words, this further moves WASI out of the foreground as it has been nothing but burden. ```diff --- a/README.md +++ b/README.md @@ -49,8 +49,8 @@ For example, here's how you can allow WebAssembly modules to read -wm, err := r.InstantiateModule(wazero.WASISnapshotPreview1()) -defer wm.Close() +wm, err := wasi.InstantiateSnapshotPreview1(r) +defer wm.Close() -sysConfig := wazero.NewSysConfig().WithFS(os.DirFS("/work/home")) -module, err := wazero.StartWASICommandWithConfig(r, compiled, sysConfig) +config := wazero.ModuleConfig().WithFS(os.DirFS("/work/home")) +module, err := r.InstantiateModule(binary, config) defer module.Close() ... ```
43 lines
1.1 KiB
Go
43 lines
1.1 KiB
Go
package examples
|
|
|
|
import (
|
|
_ "embed"
|
|
"testing"
|
|
|
|
"github.com/stretchr/testify/require"
|
|
|
|
"github.com/tetratelabs/wazero"
|
|
"github.com/tetratelabs/wazero/wasi"
|
|
)
|
|
|
|
// fibWasm was compiled from TinyGo testdata/fibonacci.go
|
|
//go:embed testdata/fibonacci.wasm
|
|
var fibWasm []byte // TODO: implement this in text format as it is less distracting setup
|
|
|
|
func Test_fibonacci(t *testing.T) {
|
|
r := wazero.NewRuntime()
|
|
|
|
// Note: fibonacci.go doesn't directly use WASI, but TinyGo needs to be initialized as a WASI Command.
|
|
wm, err := wasi.InstantiateSnapshotPreview1(r)
|
|
require.NoError(t, err)
|
|
defer wm.Close()
|
|
|
|
module, err := r.InstantiateModuleFromCode(fibWasm)
|
|
require.NoError(t, err)
|
|
defer module.Close()
|
|
|
|
fibonacci := module.ExportedFunction("fibonacci")
|
|
|
|
for _, c := range []struct {
|
|
input, expected uint64 // i32_i32 sig, but wasm.ExportedFunction params and results are uint64
|
|
}{
|
|
{input: 20, expected: 6765},
|
|
{input: 10, expected: 55},
|
|
{input: 5, expected: 5},
|
|
} {
|
|
results, err := fibonacci.Call(nil, c.input)
|
|
require.NoError(t, err)
|
|
require.Equal(t, c.expected, results[0])
|
|
}
|
|
}
|