adam (Mar 27 2024 at 20:58): adam (Mar 27 2024 at 20:58):Does the WASI package label wasi:io/error@0.2.0 correlate to preview 2 as metioned here?
I see mention of WASI preview 1, 2 and soon to be 3 and I see these versions for the WASI packages. Is there a corresponding wasi_snapshot_preview2.proxy.wasm for Preview 2 or does the name of these snapshot previews with wasmtime 19 not relate to what the WASI preview 2 readme says?
My components built with wasmtime 19 and embedding wasi_snapshot_preview1.proxy.wasm list imports for 0.2.0 so it seems like the preview1 snapshot is packaging 0.2.0 packages. Correct?
Dan Gohman (Mar 27 2024 at 21:01):Preview 2 is 0.2.x.
Ramon Klass (Mar 27 2024 at 21:01):the filename of the adapter means that it takes preview1 wasi as input, it always has the latest version as output I think
adam (Mar 27 2024 at 21:03):What would the scenario of not needing to do the embed step to adapt a component? Is it a correct understanding that the step is only needed if the runtime has preview1 and the component is using preview2?
Dan Gohman (Mar 27 2024 at 21:04):Yes; work on natively Preview 2 toolchains is underway, and when they're ready they won't need the preview1-to-preview2 adapter.
Ramon Klass (Mar 27 2024 at 21:04):compilers currently only target preview1, so you always need to adapt to get a component. People are working on a wasm32-wasip2 compiler target, once that exists you can compile components without needing to adapt
adam (Mar 27 2024 at 21:12):I see an example in wasmtime that uses wasi-common to provide WASI APIs to a runtime instance. Yesterday Alex posted a wasmtime-wasi crate example so I see two different paths forward for linking WASI APIs. There's also a crate called wasi also by the bytecodealliance.
Dan Gohman (Mar 27 2024 at 21:14):wasi-common contains a Preview 1 host implementation. Current versions of wasmtime-wasi contain a Preview 2 host implementation. Current versions of the wasi crate contains guest bindings for Preview 2 APIs.
adam (Mar 27 2024 at 21:15):And using wasi-common and wasmtime-wasi require switching to nightly Rust. Is that avoiadble?
Dan Gohman (Mar 27 2024 at 21:16):They do?
Ramon Klass (Mar 27 2024 at 21:16):(stable rust works for me)
adam (Mar 27 2024 at 21:17):can_vector from the io-extras crate
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /Users/adam/.cargo/registry/src/index.crates.io-6f17d22bba15001f/io-extras-0.18.1/src/lib.rs:19:33
|
19 | #![cfg_attr(can_vector, feature(can_vector))]
| ^^^^^^^^^^
Adding either of those two crates causes this error. Removing them compiles and runs.
Dan Gohman (Mar 27 2024 at 21:17):That.. is not supposed to happen :-}.
Ramon Klass (Mar 27 2024 at 21:18):I would run cargo clean next, I've seen the strangest things when target has been written to by different rust versions
adam (Mar 27 2024 at 21:20):cargo clean did the job
adam (Mar 27 2024 at 21:25):The crates/wasi directory in wasmtime repo is actually the crate wasmtime-wasi. Where does the wasi crate for guest bindings live?
Ramon Klass (Mar 27 2024 at 21:26):https://github.com/bytecodealliance/wasi
adam (Mar 27 2024 at 21:32):If wasmtime-wasi is the preview 2 host impl and the package used by the example update PR by Alex is wasmtime-wasi::preview1, if I use wasmtime_wasi::ctx it will be preview 2? Which would mean the adapt step wouldn't be necessary?
adam (Mar 27 2024 at 22:47):That was a question answered by your explanation of the preview1 adapting for preview2. Had to look at the code to grok it.
adam (Mar 27 2024 at 22:53):Thanks for the help everyone!
~/work/learning/learn-wasm-components/runtime/rust cargo run
Compiling runtime v0.1.0 (/Users/adam/work/learning/learn-wasm-components/runtime/rust)
Finished dev [unoptimized + debuginfo] target(s) in 1.94s
Running `target/debug/runtime`
26 is even
Last updated: Dec 23 2024 at 14:03 UTC