-
Notifications
You must be signed in to change notification settings - Fork 456
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
Make assert/invoke require constant parameters? #109
Comments
This makes sense to me. I revised several tests to work like this already, and #104 revises float32.wast's tests this way too, which I believe is the only remaining one. |
Ideally, I think, we'd not reuse wasm for the |
I don't really see a problem with having expressions as parameters. Is there one? I implemented it as such and think it is a good way of being able to cascade different calls together and ensuring the end result. I see simplicity of having the constants instead but I think expressions just allow more possibilities. |
I also think constants only makes sense. Otherwise you need to be able to On Wed, Oct 7, 2015 at 4:05 PM, jcbeyler [email protected] wrote:
|
Funny ☺. It kind of goes in the same conversation of Descartes: Doubt of everything except that you are doubting (otherwise how can you know that you are really doubting ;-)). I do see the point but I don’t see it as a real problem: Unitests that use constants for base functionality of foo è Thus assess that foo is fine Start using foo in the unitests for higher level testing. I’m ok with any decisions you make, I was just curious |
|
JavaScript `Atomics.wait` takes milliseconds, but wasm uses nanoseconds for timeout.
[test] Unify the trap message of "null function reference".
I just noticed that invoke accepts arbitrary expressions as parameters. WAVM currently generates code for each assertion, but I was hoping to get rid of that and make each assertion just call some exported function with constant parameters.
It could also go the other way and allow expressions other than invoke as the left hand side of the assertion, but what's there right now seems like an awkward trade off between power and simplicity that achieves neither.
The text was updated successfully, but these errors were encountered: