Stream: general

Topic: Send string from Rust WASM to Python wasmtime?


view this post on Zulip Keith Wipf (Aug 11 2022 at 16:24):

Hello, I'm new to WIT-Bindgen and am wondering if it's possible to compile Rust code into a WASM module that, when compiled and loaded from Wasmtime in Python, has a function that returns a Python string by using interface types? I couldn't find much documentation.

view this post on Zulip Bailey Hayes (Aug 11 2022 at 17:13):

100% the doc is too sparse for this right now. I think a quickstart tutorial for python hosts would be really helpful.

Use wit-bingen to generate host bindings using gen-wasmtime-py then generate guest bindings using gen-rust and implement both.

Creating python host:

# run this command to generate host bindings
wit-bindgen wasmtime-py --import string-provider.wit
python -m pip install wasmtime
# Then use those to implement host logic for consuming string in python
# Here's how you use wasmtime-py:
# https://github.com/bytecodealliance/wasmtime-py#usage
# see also tests using python as a host showing wit-bindgen bindings:
# https://github.com/bytecodealliance/wit-bindgen/blob/main/tests/runtime/many_arguments/host.py

Creating Rust guest code (code that is in the Wasm module).
Add the wit-bindgen dependency, see this.

// this is equivalent to generating the guest bindings  with the following
// wit-bindgen rust-wasm --export string-provider.wit
wit_bindgen_rust::export!("string-provider.wit");
...
// your implementation
A language binding generator for WebAssembly interface types - wit-bindgen/crates/gen-wasmtime-py at main · bytecodealliance/wit-bindgen
A language binding generator for WebAssembly interface types - wit-bindgen/crates/gen-rust at main · bytecodealliance/wit-bindgen
Tools to streamline development of Wasm UDFs for SingleStoreDB. - singlestore-wasm-toolkit/Cargo.toml at main · singlestore-labs/singlestore-wasm-toolkit

view this post on Zulip Keith Wipf (Aug 13 2022 at 21:08):

I fiddled around and found witgen which was supposed to help me generate a .wit file for my functions but it doesn't seem compatible with wit-bindgen's way of making you define a struct and an impl block and putting functions in that, it expectes them to be top level. I eventually managed to get it to spit out this:
hello-world: func() -> string
With the rust code:

wit_bindgen_rust::export!("string-provider.wit");
struct StringProvider;
impl string_provider::StringProvider for StringProvider {
fn hello_world() -> String {
"Hello!".to_string()
}
}
I also got it to compile and ran wit-bindgen and now I have bindings.py which I'm not sure how to use.
I always thought that WASM modules would have a special interface types section or something within the WASM module itself, runtimes like Wasmtime would read it and generate functions that convert from Rust strings into Python strings ETC and no need to generate any .wit files, but I guess not.
Also while compiling with:
cargo build -j1 --target=wasm32-wasi
I keep getting dozens and dozens of messages like:
'+ssse3' is not a recognized feature for this target (ignoring feature)
'-sgx' is not a recognized feature for this target (ignoring feature)
'-shstk' is not a recognized feature for this target (ignoring feature)
'+cmov' is not a recognized feature for this target (ignoring feature)
'-avx512vbmi' is not a recognized feature for this target (ignoring feature)
'-amx-int8' is not a recognized feature for this target (ignoring feature)
'
Is there something to turn that off?

view this post on Zulip bjorn3 (Aug 13 2022 at 21:49):

Do you have a global .cargo/config.toml file setting those target features?

view this post on Zulip bjorn3 (Aug 13 2022 at 21:50):

Those don't get set automatically for any target, not wasm, but also not x86_64 where they originate from.

view this post on Zulip Keith Wipf (Aug 19 2022 at 20:26):

Now I remember putting one there a year ago which adds:
rustflags = "-Ctarget-cpu=native"
I'd think that'd only enable the supported features though. Anyway getting rid of it solved it. Thanks.


Last updated: Oct 23 2024 at 20:03 UTC