adam (Mar 23 2024 at 04:12): adam (Mar 23 2024 at 04:12):Any wasm file, whether it's before component embed or after gets an exit code 0 and no output with wasm-tools validate component asdf.wasm --features component-model.
The same wasm file thrown at wasm-tools component targets asdf.wit asdf.wasm (or asdf.embed.wasm) gives me:
error: failed to validate encoded bytes
Caused by:
0: expected a version header for a component (at offset 0xc)
When I use asdf.component.wasm (after component embed and component new --adapt) then I get:
# wasm-tools component targets ../wit/asdf.wit asdf.component.wasm
error: failed to validate encoded bytes
Caused by:
0: type mismatch for import `library`
missing import named `wasi:io/error@0.2.0` (at offset 0x1a0cd)
Should validate component fail a validation check before certain wasm-tools steps or will it always be valid component wasm, even without the metadata and embed, if it's compiled against a WIT?
adam (Mar 23 2024 at 19:29):The WASM component build is working, validate doesn't error or warn, yet I get Invalid input WebAssembly code at offset 4: unknown binary version when running the component from wasmtime-go.
Anyone have eyes for where I went wrong with my simian kludging together of my first WASM program? I'm happy to contribute to docs and guides in gratitude.
https://github.com/eighty4/learn-wasm-components
https://github.com/bytecodealliance/wit-bindgen/issues/906
Peter Huene (Mar 24 2024 at 00:57):Only the Rust API supports components at the moment, as there currently is no C API for the component model for the other languages to bind to
Peter Huene (Mar 24 2024 at 00:57):Module only supports a WebAssembly module, not a component
Peter Huene (Mar 24 2024 at 00:57):the error message is a horrible one that needs to be fixed
Peter Huene (Mar 24 2024 at 01:00):fixed in wasm-tools, that is; it knows it's a component
adam (Mar 24 2024 at 18:01):Are there commands with wasm-tools where I could inspect a wasm file kinda the way you can dump info about elf headers with a binary?
adam (Mar 24 2024 at 18:03):I was worried this would be the case because wasmtime-go hasn't been updated in over a year.
If Rust is the only platform that runs components, does that mean there's no way with another golang runtime to run a function compiled to WASM? A module means it's just a program that can be run and you have to manually map binary data in and out of the function?
I was waiting for the component model for years so I actually don't know how the OG method works that folks have used for consumer facing products like the Envoy and Istio plugin APIs.
Tarek Sander (Mar 24 2024 at 19:17):AFAIK the component model is a cross-language agreement on how to pass data between WASM instances or an instance and the host, so a golang runtime would just have to implement that to run components. It just so happens that the bleeding edge of WASM runtimes is in Rust. The "OG method" is to define the data layout yourself. WIT is designed to generate code in the host and client languages to handle that instead of doing it manually.
Alex Crichton (Mar 25 2024 at 15:00):The component runtimes I know of are Wasmtime (the Rust API), JS (via Node via jco), and Python (via wasmtime-py and bindings like jco). I can confirm that wasmtime-go, while we're still updating it, does not have support for components. Wasmtime's C API does not have support for components yet either.
adam (Mar 25 2024 at 15:31):I made an assumption that if wasmtime-go was using C bindings, they would be C bindings of the Rust library.
Alex Crichton (Mar 25 2024 at 15:36):Yes wasmtime-go is using the C API of Wasmtime, not the Rust API
Last updated: Nov 22 2024 at 17:03 UTC