Frank Rehwinkel (May 13 2024 at 15:06): Frank Rehwinkel (May 13 2024 at 15:06):May I ask a completely naive question? How is the work being done on the component-model's PR #336 named "formalize component value definitions" related to the wasm-wave crate which reached version 0.5.0 some three months ago? Is it related? Are they opposites sides of a coin? Was one the precursor of the other?
I will admit I don't really know what this "Value Encoding" means. Seems like Wasm components are being encoded to binary well already and allowing all sorts of composition.
Lann Martin (May 13 2024 at 15:17):WAVE is a human-read/writeable encoding of component model values that is (currently) completely outside of the spec. That PR is about adding an encoding of value constants into the component spec, which would be primarily for machine consumption. They aren't really related apart from both being representations of component values.
Frank Rehwinkel (May 13 2024 at 15:23):Thanks for that. Two questions?
What would the human-readable coding with wasm-wave show on a component that wasm-tools print does not? Is it kind of the same thing, but it would allow a parser to then go in the other direction, kind of like Wasm core modules could go from binary to .wat files and back?
And since WASIp2 was implemented already, what does it mean that binary value constants aren't in the spec? (I hope this doesn't sound like an obnoxious question.)
Lann Martin (May 13 2024 at 15:28):Encoded constants aren't required by any feature currently in the spec. They are being added to support a new "Value Definitions" feature in that PR.
Lann Martin (May 13 2024 at 15:29):Currently, any constant values a component uses will be encoded within the core module in a guest-language-dependent way. They only get encoded (as component values) when they are used in an imported function call.
Frank Rehwinkel (May 13 2024 at 15:36):Oh, thank you. That shed light on the issue for me.
Pat Hickey (May 13 2024 at 15:48):in particular we were hoping that wave could be the format we use for accepting arguments to invoke on the CLI, which doesn't presently work (came up recently https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/trying.20to.20hand.20create.20a.20component/near/438117527)
Pat Hickey (May 13 2024 at 15:49):I don't recall what was blocking that from continuing, when I looked at wave it looked great so maybe its just that nobody has prioritized adding it to wasmtime-cli
Lann Martin (May 13 2024 at 15:50):Yes I just haven't followed up: https://github.com/bytecodealliance/wasmtime/issues/7326
Pat Hickey (May 13 2024 at 15:51):right on. well, we know you have been busy with lots of important stuff! maybe we could even make this an issue suitable for a new contributor?
Lann Martin (May 13 2024 at 15:53):Wave needs to be updated to Wasmtime 20's new component Val API but otherwise it should be relatively straightforward.
Lann Martin (May 13 2024 at 15:54):Also might want to move it into the BA org?
Pat Hickey (May 13 2024 at 15:55):yeah, maybe as a crate in the wac repo?
Frank Rehwinkel (May 13 2024 at 15:56):I was able to get a forked version ofwepl compiled for the new Wasmtime. The Val API did change but it was mostly very easy.
Pat Hickey (May 13 2024 at 15:56):yeah wasmtime repl would be the ideal spot for that to land
Lann Martin (May 13 2024 at 15:57):Not sure we'd want wasmtime to depend on wac (unless its going to anyway) never mind, "crate in the wac repo" doesn't mean "is wac" :smile:
Pat Hickey (May 13 2024 at 15:59):the alternative is to have it in wasm-tools, which could work as well, and might make it easier to keep dep bumping cycles shorter since wac depends on wasmtime
Pat Hickey (May 13 2024 at 16:00):(iirc, i understood that wac could run wasm as its extension system so i assume its using wasmtime-the-crate to do that)
Lann Martin (May 13 2024 at 16:02)::point_of_information: I believe that is planned but hasn't landed yet
Lann Martin (May 13 2024 at 16:02):https://github.com/lann/wasm-wave/issues/33
Frank Rehwinkel (May 14 2024 at 12:45):I'll submit a PR for this soon. I have wasm-wave compiling and passings its unit tests for Wasm 20 now.
Lann Martin (May 14 2024 at 12:50):Great! I'd be happy to discuss this too; I had the vague notion that I might need/want to redesign WasmType and WasmValue
Frank Rehwinkel (May 14 2024 at 12:57):Of course. Given how wasmtime redesigned its featured values and types, I kept thinking maybe how wasm-wave was wrapping those features could be changed. But I had a feeling a straightforward upgrade wouldn't be hard and could give an easier redesign point. And no ego here. I'm happy if you are willing to look at it and you can decide what to do then. I'll admit I've made these changes without a complete understanding how the program works, basically letting the compiler tell me what to look at and relying on the 54 unit tests to tell me if it seemed to be regressing. We can discuss more in the PR in a few minutes.
Lann Martin (May 14 2024 at 13:00):Yeah if it works I'm happy to merge and consider other changes later
Lann Martin (May 24 2024 at 13:19):Thanks to @Frank Rehwinkel for sticking with me as I figured out what interface changes were needed to support Wasmtime's new component type system! Their PR has been released with wasm-wave 0.6.0, bringing support for Wasmtime 21.
Last updated: Nov 22 2024 at 16:03 UTC