lann opened issue #7326:
You can currently call a core module export with
wasmtime run --invoke <func> <module.wasm> [params...]
, but using--invoke
with components is not supported.While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
I see a few ways that WAVE could be used here:
The simplest extension of the existing feature would just add WAVE parsing for params:
wasmtime run --invoke my-func component.wasm '"arg1"' 2 '[3,4]'
A variation of this could allow "undelimited" values (which would require further spec/implementation work), e.g.:
wasmtime run --invoke my-func component.wasm arg1 2 3,4
A more radical change would be to change the way arguments are passed to look more like a "normal" function call, which might help with some confusion with the existing
--invoke
syntax:
wasmtime run --invoke 'my-func("arg1", 2, [3, 4])'
component.wasmMake some other even more radical (breaking, probably) change to how
--invoke
worksI have implemented a prototype of the "function call" encoding option 3, though I would actually prefer the "undelimited" option 2 if the params could appear immediately after the function name.
lann commented on issue #7326:
Another open question here would be how to reference functions that aren't top-level exports, e.g. something like
wasi:cli/run@0.2.0-rc-2023-11-05::run()
, though hopefully we can have something a little nicer than that.
lann edited a comment on issue #7326:
Another open question here would be how to reference functions that aren't top-level exports, e.g. something like
wasi:cli/run@0.2.0-rc-2023-11-05::run()
, though hopefully we can have something a little nicer than that.Update: A suggestion from @pchickey on Zulip is to allow the "path" to a function export to be omitted as long as the result isn't ambiguous. We'd still presumably want some way to disambiguate if necessary but that sounds good to me.
alexcrichton commented on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
HarikrishnanBalagopal commented on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
Is there any update on this issue?
While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
$ wasmtime run --wasm-features component-model --invoke add add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: using `--invoke` with components is not supported
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
$ wasmtime run --wasm-features component-model --invoke add add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: using `--invoke` with components is not supported
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
$ wasmtime --version wasmtime-cli 17.0.0 (ab5a4484e 2024-01-25) $ wasmtime run --wasm component-model=y --invoke=add add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: using `--invoke` with components is not supported
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
I was very confused seeing that phrase for the first time and wondering whatsix-to-one
had to do withhalf-dozen
:rolling_on_the_floor_laughing:While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
$ wasmtime --version wasmtime-cli 17.0.0 (ab5a4484e 2024-01-25) $ wasmtime run --wasm component-model=y --invoke=add add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: using `--invoke` with components is not supported
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
I was very confused seeing that phrase for the first time and wondering whatsix-to-one
had to do withhalf-dozen
:rolling_on_the_floor_laughing:While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue now that WASI preview 2 has been officially released?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
$ wasmtime --version wasmtime-cli 17.0.0 (ab5a4484e 2024-01-25) $ wasmtime run --wasm component-model=y --invoke=add add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: using `--invoke` with components is not supported
HarikrishnanBalagopal edited a comment on issue #7326:
I think adding this is a great idea, and I like the idea of having a well-defined encoding for types-to-strings-and-back like WAVE, so I'm all for this :+1:. As to the bikesheddy details, I'm down to defer to you and see how it plays out over time, these are all six-to-one-half-dozen to me.
six-of-one
I was very confused seeing that phrase for the first time and wondering whatsix-to-one
had to do withhalf-dozen
:rolling_on_the_floor_laughing:While it should (presumably) be fairly straightforward to add support for invoking nullary functions, it would be much more useful to be able to pass arguments, which brings up the challenge of encoding complex parameter values. I have developed a component model value encoding (and library) called WAVE which could be used for this.
Is there any update on this issue now that WASI preview 2 has been officially released?
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I came here from the tutorial on wasm component model https://component-model.bytecodealliance.org/language-support.html#building-a-component-with-wasm-tools
Running a Component with Wasmtime
You can "run" a component by calling one of its exports. Hosts and runtimes often only support running components with certain exports. The wasmtime CLI can only run "command" components, so in order to run the add function above, it first must be composed with a primary "command" component that calls it. See documentation on running components for more details.
$ wasmtime --version wasmtime-cli 17.0.0 (ab5a4484e 2024-01-25) $ wasmtime run --wasm component-model=y add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: exported instance `wasi:cli/run@0.2.0` not present $ wasmtime run --wasm component-model=y --invoke=add add.component.wasm Error: failed to run main module `add.component.wasm` Caused by: using `--invoke` with components is not supported
lann commented on issue #7326:
Is there any update on this issue now that WASI preview 2 has been officially released?
I think this just hasn't been a priority for anyone. WAVE has evolved a bit in the interim and is expected to make an appearance in some other Bytecode Alliance tooling pretty soon which should help iron out any remaining bugs or process issues.
If it's too difficult to implement full parameter passing from the CLI, what about just supporting nullary (and possibly integer) functions for now?
I think this would be entirely fine as a first step. There is some nuance just in identifying an export, but I don't see much downside to starting with a very constrained/explicit implementation (nullary, fully-qualified export name), especially if there is a rough idea of how to extend it from there.
Last updated: Nov 22 2024 at 17:03 UTC