Stream: git-wasmtime

Topic: wasmtime / PR #8957 Add docs to `wasmtime-c-api-macros` g...

Wasmtime GitHub notifications bot (Jul 15 2024 at 11:19):

Robbepop opened PR #8957 from Robbepop:rf-add-docs-to-c-api-macros to bytecodealliance:main:

I didn't know what some of those methods even do. The only docs I could find where the Wasmtime doxygen docs which only stated that most of the methods are simply not implemented.

So in parts I hope to improve Wasmtime C-API by improving the docs situation and in other parts I hope to find their meaning with this PR. :)

Wasmtime GitHub notifications bot (Jul 15 2024 at 11:19):

Robbepop requested elliottt for a review on PR #8957.

Wasmtime GitHub notifications bot (Jul 15 2024 at 11:19):

Robbepop requested wasmtime-core-reviewers for a review on PR #8957.

Wasmtime GitHub notifications bot (Jul 15 2024 at 11:20):

Robbepop edited PR #8957:

I didn't know what some of those methods even do. The only docs I could find where the Wasmtime doxygen docs which only stated that most of the methods are simply not implemented.

So in parts I hope to improve Wasmtime C-API by improving the docs situation and in other parts I hope to find their meaning with this PR. :)

Due to missing knowledge I consider the automatically generated docs (of this PR) of get/set_host_info, as_ref and as_ref_const as temporary until we (I) know better.

Wasmtime GitHub notifications bot (Jul 15 2024 at 11:21):

Robbepop edited PR #8957:

I didn't know what some of those methods even do. The only docs I could find where the Wasmtime doxygen docs which only stated that most of the methods are simply not implemented.

So in parts I hope to improve Wasmtime C-API by improving the docs situation and in other parts I hope to find their meaning with this PR. :)

Due to missing knowledge I consider the automatically generated docs (of this PR) of get/set_host_info, as_ref and as_ref_const as temporary until we (I) know better.

Rendered auto generated docs:


Wasmtime GitHub notifications bot (Jul 15 2024 at 11:24):

Robbepop updated PR #8957.

Wasmtime GitHub notifications bot (Jul 15 2024 at 15:47):

alexcrichton submitted PR review:

Thanks!

Looks like you've found that some of these aren't supported which is intentional, but otherwise having docs is deifnitely an oversight :+1:

Wasmtime GitHub notifications bot (Jul 15 2024 at 16:02):

alexcrichton merged PR #8957.

Wasmtime GitHub notifications bot (Jul 15 2024 at 20:45):

Robbepop commented on PR #8957:

Hmmm, I really wanted to learn what those APIs I mentioned in my first post are about. They are not properly documented in the standard C API and it is still unclear to me what they are supposed to do. But at least Wasmtime now has a bit better documentation story for its Rust C API. :)

Wasmtime GitHub notifications bot (Jul 15 2024 at 20:46):

Robbepop edited a comment on PR #8957:

Hmmm, I really wanted to learn what those APIs I mentioned in my first post are about. They are not properly documented in the standard C API (or I failed to find their docs) and it is still unclear to me what they are supposed to do. But at least Wasmtime now has a bit better documentation story for its Rust C API. :)

Wasmtime GitHub notifications bot (Jul 15 2024 at 20:52):

alexcrichton commented on PR #8957:

Oh sorry, I can try to add more color but honestly I'm not certain what they are myself. The upstream wasm-c-api proposal to wasm has been largely inactive for quite some time now and AFAIK there's not much drive/push to revinvigorate it or keep it going. In that sense the best option would be to probably open an issue on the repository itself.

If I had to hazard a guess, I believe that the intention was that all pointer-lookalike-things could be turned into generic references which could then be converted back out at some point. I believe the original goal was to eventually unify the wasm type system itself to allow passing around first-class-references to more than just functions but also tables/memories/etc. In the interim time I don't believe that's panned out and in Wasmtime we don't implement any of these because they don't actually map to internals of Wasmtime.

AFAIK there also hasn't been much usage of the wasm-c-api header file as a means of integrating with a wasm engine. All usage I've seen additionally requires implementation-specific APIs (e.g. wasmtime_* in the Wasmtime C API). Many out-of-browser engines I've seen also don't implement this API as well.

Overall I don't think things are in a state where it's expected someone can walk in and see a vibrant and well documented ecosystem of engines and users all interoperating with this API. I believe that was an original goal, but it hasn't quite panned out.

Wasmtime GitHub notifications bot (Jul 15 2024 at 21:50):

Robbepop commented on PR #8957:

@alexcrichton Thank you so much for the elaborated response. It is also really good to know (albeit sad) about the state of the Wasm C API maintenance. I hoped it was achieving its set goals. At least I plan to implement it in Wasmi soon(TM).

Also thanks a lot for your elaborated guess what you think those APIs are meant to do. What you said makes kinda sense to me. I will take your suggestion of posting further questions directly in the repository. :)

Wasmtime GitHub notifications bot (Jul 15 2024 at 21:51):

Robbepop edited a comment on PR #8957:

@alexcrichton Thank you so much for the elaborated response. It is also really good to know (albeit sad) about the state of the Wasm C API maintenance. I hoped it was achieving its set goals. At least I plan to implement it in Wasmi soon(TM) to allow non-Rust environments to use Wasmi.

Also thanks a lot for your elaborated guess what you think those APIs are meant to do. What you said makes kinda sense to me. I will take your suggestion of posting further questions directly in the repository. :)

Last updated: Dec 23 2024 at 13:07 UTC