Skip to content
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

No --enable-experimental-io-devices switch in Wasmer 2.0.0 on Windows #2695

Closed
niutech opened this issue Nov 28, 2021 · 4 comments · Fixed by #2805
Closed

No --enable-experimental-io-devices switch in Wasmer 2.0.0 on Windows #2695

niutech opened this issue Nov 28, 2021 · 4 comments · Fixed by #2805
Labels
bug Something isn't working priority-high High priority issue

Comments

@niutech
Copy link

niutech commented Nov 28, 2021

I have downloaded the latest version of Wasmer 2.0.0 on Windows 10 x64 and wanted to use the I/O devices, so I typed:

wasmer.exe run --enable-experimental-io-devices wasmerboy.wasm

but I got this output:

error: Found argument '--enable-experimental-io-devices' which wasn't expected, or isn't valid in this context
        Did you mean --enable-simd?

Please include I/O devices in Windows build so that I could run wasmerboy.wasm as a standalone GUI app.

@niutech niutech added the bug Something isn't working label Nov 28, 2021
@Amanieu
Copy link
Contributor

Amanieu commented Feb 9, 2022

Does this still happen in the latest version of wasmer?

@niutech
Copy link
Author

niutech commented Feb 9, 2022

Yes, in Wasmer 2.2.0-rc1 I still get error: Found argument '--enable-experimental-io-devices' which wasn't expected, or isn't valid in this context

@Amanieu
Copy link
Contributor

Amanieu commented Feb 9, 2022

@syrusakbary Is there any reason not to enable the experimental-io-devices Cargo feature by default so it is included in the release builds?

@Amanieu Amanieu added the priority-high High priority issue label Feb 23, 2022
@syrusakbary
Copy link
Member

I think enabling experimental-io-devices required fixing some dependencies (if I recall properly we disabled it because one depdency was failing on unix), so that's why it was not enabled. But once we do update the depdenencies I think it should be good to go

bors bot added a commit that referenced this issue Feb 25, 2022
2805: Enable `experimental-io-devices` by default r=Amanieu a=Amanieu

Fixes #2695

2806: Fix drop order for Module fields r=Amanieu a=Amanieu

The field ordering here is actually significant because of the drop
order: we want to drop the artifact before dropping the engine.

The reason for this is that dropping the Artifact will de-register the
trap handling metadata from the global registry. This must be done before
the code memory for the artifact is freed (which happens when the store
is dropped) since there is a chance that this memory could be reused by
another module which will try to register its own trap information.

Note that in Rust, the drop order for struct fields is from top to
bottom: the opposite of C++.

In the future, this code should be refactored to properly describe the
ownership of the code and its metadata.

Fixes #2434


Co-authored-by: Amanieu d'Antras <[email protected]>
Co-authored-by: ptitSeb <[email protected]>
@bors bors bot closed this as completed in cdb7dc8 Feb 25, 2022
ptitSeb pushed a commit that referenced this issue Oct 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority-high High priority issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants