Wasmtime GitHub notifications bot (Mar 10 2020 at 19:13): Wasmtime GitHub notifications bot (Mar 10 2020 at 19:13):darinmorrison commented on Issue #677:
@alexcrichton I'm not sure how it fits into the current plans (per #1271) but I would like to volunteer to continue the work you started with https://github.com/bytecodealliance/wasmtime/pull/1013.
I spent some time going through the source to get an idea of what is involved and have already started adding some of the missing instructions (from instr.md) in a local branch (not published yet).
I might need guidance at various points (around strings, compilation, etc.) but I have time to focus on it and I've been looking for something more substantial to work on.
Wasmtime GitHub notifications bot (Mar 10 2020 at 21:25):alexcrichton commented on Issue #677:
@darinmorrison that'd be awesome, and I'd be happy to help!
I think the TODO list on that PR covers pretty well the major two remaining bits, and I'd probably recommend tackling the first two earlier rather than later to ensure that all the various integration points are largely working before an interpreter becomes more fleshed out.
Feel free to ping me on zulip or here if you've got questions though!
Wasmtime GitHub notifications bot (Apr 06 2020 at 00:40):rheinardkorf commented on Issue #677:
@alexcrichton , based on the last comment here https://github.com/bytecodealliance/wasmtime/pull/1289 it looks like @darinmorrison is not able to continue on this work.
I can't even begin to fathom how all this works, nor do I have the capacity right now to work on things. I'm justing pinging it here so that the "interface types" work doesn't disappear. Its important :D
Wasmtime GitHub notifications bot (Apr 07 2020 at 16:07):Serentty commented on Issue #677:
That's a good point about encodings, although I would initally sort of hope that we could preserve "utf-8 everywhere" as long as possible, but not with copies.
I don't think that interface types are the place to push UTF-8. Ultimately it's up to the languages, not the bytecode. No one will _choose_ which encoding to used based on what interface types do, they'll choose based on what the languages involved do. Supporting more Unicode encodings means removing redundant copies, it's as simple as that. It won't lead to some dystopia where everyone is switching to UTF-16 because it wasn't barred up enough.
Wasmtime GitHub notifications bot (Apr 08 2020 at 10:26):tschneidereit commented on Issue #677:
I don't think that interface types are the place to push UTF-8
Note that when it comes to Interface Types, we'll implement what gets standardized, so if the Interface Types proposal ends up only supporting UTF-8, then we'll only implement that. I.e., arguments for additional encoding should be made to the WebAssembly CG, not here.
Wasmtime GitHub notifications bot (Apr 08 2020 at 19:47):Serentty commented on Issue #677:
Thanks, I left a comment on their repository saying the same thing.
Wasmtime GitHub notifications bot (Oct 01 2020 at 21:51):onehundredfeet commented on Issue #677:
Sorry for the uninformed question, but how can I enable interface types at the moment? Do I need the wasm-interface-types crate? Or is it a total no-go atm?
Wasmtime GitHub notifications bot (Oct 01 2020 at 22:52):alexcrichton commented on Issue #677:
Unfortuantely at this time there's not a prototype or a switch to turn on. This is not implemented, so testing this out (or even playing around with it) will have to wait until someone implements this.
Wasmtime GitHub notifications bot (Feb 02 2021 at 11:01):slightknack commented on Issue #677:
This is not implemented, so testing this out (or even playing around with it) will have to wait until someone implements this.
@alexcrichton Just out of curiosity, what is needs to be implemented for interface types to be supported? Is there a set of issues / roadmap / milestone we can refer to? Or is just a matter of reading through the spec and implementing the appropriate features in accordance with wasmtime's API?
Wasmtime GitHub notifications bot (Feb 02 2021 at 16:14):alexcrichton commented on Issue #677:
I'm not aware of a milestone as-is at this time. The main blocker is still planning work to happen on this. There's a number of moving parts, though, especially in that the specification itself is not stable and is a moving target. This will likely be an effort that's much larger than simply implementing the current state of the specification in wasmtime itself.
Wasmtime GitHub notifications bot (Mar 05 2021 at 17:47):morigs commented on Issue #677:
Is it possible to use some temporary workaround? For example witx? (especially after #2659 has been merged)
I want to experiment with the implementation of the plugin system using wasm, but inventing your own ABI and manipulating memory and pointers every time you want to pass a struct to a function is kinda hell :big_smile:
Wasmtime GitHub notifications bot (Mar 08 2021 at 15:15):alexcrichton commented on Issue #677:
Yes it's definitely true that working with raw pointers and such is painful and error-prone today. We're working on exactly what you're thinking, though, which is a system to use
*.witxfiles to generate bindings for consumers and producers of wasm files. It won't be full interface types (no support inwasmtime-the-crate, but support generating code forwasmtime-the-crate), but we hope it's a good step towards interface types.
Wasmtime GitHub notifications bot (Mar 16 2021 at 17:06):morigs commented on Issue #677:
Looking forward to a working prototype of what you've mentioned!
Please let us know when it will be possible to try new witx in battle :sunglasses:
Last updated: Nov 22 2024 at 16:03 UTC