Stream: git-wasmtime

Topic: wasmtime / issue #7326 Add support for components to `was...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 22 2023 at 20:47):

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:

  1. 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]'

  2. 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

  3. 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.wasm

  4. Make some other even more radical (breaking, probably) change to how --invoke works

I 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.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 22 2023 at 20:59):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 23 2023 at 21:38):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 23 2023 at 22:07):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:03):

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?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:03):

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?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:07):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:07):

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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:07):

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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:15):

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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:17):

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 what six-to-one had to do with half-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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:19):

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 what six-to-one had to do with half-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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 12:22):

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 what six-to-one had to do with half-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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 30 2024 at 13:48):

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