-
-
Notifications
You must be signed in to change notification settings - Fork 673
assemblyscript loader needs adapation (chrome) #295
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
Comments
Yeah, I think we'll need to fix this. It's just the way it is because it was easier to share code between the synchronous and asynchronous APIs, but there might be other ways to achieve the same. |
Please let me know if this fixes it for you :) |
This is what I get when using
I tried to adapt the code to see where the issue might be.
I moved the await outside of the return to see what the result was.
This got solved by adding:
Apparently the abort function is required? The result is the following: Chrome version: 69.0.3497.100 (Official Build) (64-bit) [EDIT] Forgot to mention: |
The way I solved it for my project was:
I made the instantiate and co async and only changed the instance:
|
I see, yeah, I forgot about |
Yes, it appears to work now. Thanks. |
Chrome limits the use of WebAssembly.Instance to files <= 4KB
I had to copy and adapt the assemblyscript loader to be able to use it correctly.
This issue has also been mentioned here: #240
From the current docs:
Note that although instantiateStreaming is a promise, the underlying implementation still calls the "instantiate" function which calls WebAssembly.Instance
My proposal would be to change all exposed loader instantiate functions to async and replace the underlying instantiate function to use:
var instance = await WebAssembly.instantiate(module, imports);
Note:
This change would break the current docs and loader.
The text was updated successfully, but these errors were encountered: