-
Notifications
You must be signed in to change notification settings - Fork 161
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
Configure the namespace of the imports functions #25
Labels
Comments
YaronWittenstein
changed the title
Configure the namespace of the imported function
Configure the namespace of the imports functions
Jun 4, 2019
Thanks for the proposal! What do you think about this API: wasm.NewImports().
Namespace("env").
Append("sum", sum, C.sum).
Append("f", f, C.f).
Namespace("wasi").
Append("log", log, C.log) Would you like it? It's more like a tree. |
@Hywan that's even better! I guess the default namespace will be |
Correct, |
Hywan
added
📦 component-extension
About the Go extension
and removed
📦 component-runtime
About the Wasm runtime
labels
Jun 4, 2019
bors bot
added a commit
that referenced
this issue
Jun 4, 2019
29: feat(import) Add `Imports.Namespace` to set the current import namespace r=Hywan a=Hywan Fix #25. Basically, this patch allows to define imported function in any namepace. The `Imports.Namespace` sets the current namespce for the next defined imported functions: ```go wasm.NewImports().Namespace("ns").Append("f", f, C.f) ``` By default, the namespace is `env`, so both statements are identical: ```go wasm.NewImports().Namespace("env").Append(…) wasm.NewImports().Append(…) ``` To register imported functions in different namespaces, one writes: ```go wasm.NewImports().Namespace("ns1").Append(…).Append(…).Namespace("ns2").Append(…).Append(…)… ``` Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Currently, the
NewImports()
hard-codes the import namespace asenv
.If we compile a Rust program to WASM file, then the Rust compiler also hardcodes the
import namespace as
env
too (so the current wasmer go binding the Rust wasm output files play well together)However, if we patch a wasm file import namespace to something else (different than
env
), then we won't be able to use it via the golang wasmer bindingProposed solution
Instead of
Have this API:
Thank you! @Hywan :)
The text was updated successfully, but these errors were encountered: