-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add annotation framework for Wasm interfaces #519
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @electrum for putting this up to show where you are going, super useful!
Before jumping on a solution that is going this "high level" I would love to share some context regarding (my limited understanding of) CM, integration frameworks(extistm/wasm-bindgen/etc.) and the landscape we know about.
As a full disclosure, I'm comfortable moving forward and merging PRs up to:
- my proposal in Experimental Bindgen for Chicory modules #506 moving to an annotation processor
- this PR, without handling of Alloc / Free/ String/ Buffer etc.
(probably the final result will look pretty similar)
Would you be able to join tomorrow's call?
Alternatively, we can setup something ad-hoc, possibly, I'd like to have @evacchi and Ben's experience on the table.
Let's talk about it tomorrow on the call. |
import com.dylibso.chicory.runtime.Instance; | ||
import com.dylibso.chicory.wasm.types.Value; | ||
|
||
@WasmModule |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more inline with what I was thinking. I like the annotation approach and providing explicit c types. What I think we're trying to accomplish is more akin to what JNA does today. Not necessarily write the high-level bindings for you yet, but give you some types and code to keep you from having to explicitly encode the ABI level details when we can just borrow from some known ABI and types (usually C). This reduces repetition and mistakes as @andreaTP pointed out.
I can't make the call today but I'd vote for this approach. Feel free to make a decision without me though I trust y'all to figure out the right approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the annotation approach and providing explicit c types.
Agreed, thanks for your input here @bhelx 👍
This is an alternative approach to #506. See
Demo
andDemoGenerated
for what the interface looks like.It still needs actual runnable tests, maybe the OPA code plus some examples from
wasm-corpus
, but I wanted to put this up now to get some feedback. Also, needs tests for error handling.