-
Notifications
You must be signed in to change notification settings - Fork 794
WASM Support #96
Comments
@gakonst following up on this, because I just saw ethabi Would it actually be worth it to support wasm/no_std? I can't really think of a good use case... That being said, I think we can get the problems in |
I don't have a great use-case in mind either, and candidly, feels like doing async stuff over wasm/ffi would be a big pain :P I think it'd be great if the crate is in a state where it compiles with no_std/wasm-pack, so that if anybody ever wanted to build things that way, they'd be able to. |
async in wasm is not as bad as it seems. You can convert to/from promises relatively easily. To be honest, my approach would be to ensure that the |
Agreed, exactly what I meant above |
* chore: update cargo lock * test: add contract emitting all logs we want to check * feat: add logic for finding debug logs and printing them * feat(runner): add logs to the test result and print at cli * feat(evm): require evm impls to return logs at end of call * chore: empty debug logs vector for evmodin * feat(evm): raw call returns executor log non-cheatcode execcutors return empty * feat(evm): move `logs` call to trait impl * chore: adjust tests for new param * feat(evm): return logs from setup fn call * feat(sputnik): clear evm logs after call execution * feat(runner): merge setup + normal execution logs * feat(cli): make cli log output match upstream * feat(evm): return logs from deployment call so we log constructor logs * feat(runner): merge constructor logs with the rest * chore: adjust tests for new params * test: use logs from evm.call instead of manually querying them
What is the WASM support status on this lib?
What needs to be done?
The text was updated successfully, but these errors were encountered: