Closed wanderingbort closed 6 years ago
Note that one of the new requirements is for our toolchain to output binary WASM. That kind of makes this issue irrelevant.
Note: In the issue https://github.com/EOSIO/eosjs/issues/58, we compile wast to binary in another library then publish the resulting wasm:
const wasm = Buffer.from(binaryen.parseText(code).emitBinary())
This broke when a user upgraded the binaryen npmjs library but worked when they digressed to an older version. I'll make sure I keep a version in my docs for binaryen..
Having a full blown wast -> wasm transpiler is quite a heavy requirement for a 3rd-party lib.. as I'm building eos-go
.. a Go lib, I'm constantly pulling my hair to obtain a valid .wasm
out of compiled contracts (as I don't always have an old wat2wasm
binary nearby).
@spoonincode do you know if outputting .wasm
will make it into RC2 ?
No, not making RC2. I put a bet on using a new clang6/7 based compiler for our WASM compiler that outputs binary WASM natively. Unfortunately getting the new compiler working well took longer than expected and won't make RC2.
No ATC needed; unit tests should have this well covered that we didn't break something
Currently with Angular 6 and binaryen 37.0.0 I am receiving error:
Module not found: Error: Can't resolve 'crypto' in 'D:\Project\node_modules\binaryen' ERROR in ./node_modules/binaryen/index.js Module not found: Error: Can't resolve 'fs' in 'D:\Project\node_modules\binaryen' ERROR in ./node_modules/binaryen/index.js Module not found: Error: Can't resolve 'path' in 'D:\Project\node_modules\binaryen'
Reference is looking like:
import * as binaryen from 'binaryen'
EOS declaration:
eos = Eos({
keyProvider: plainTextKey,
binaryen: binaryen
})
Description
WebAssembly/Spec#599 changed the syntax for
call_indirect
. We responded with #1366 as part of our node and client code. As a result, we should be able to ingest both the old and new formats. However, the version ofs2wasm
which is built in our toolchain pre-dates the spec change and therefore produces the old format. While this is not a problem for our client software, it is a problem for other tools our users may employ and as a supporter of the Standards we, should endeavor to produce the most up-to-date WAST files.Requirements
.wast
files produced by our toolchain should support the latest WebAssembly/Spec requirements.We should continue to support deprecated formats as long as doing so does not prevent us from supporting the current spec.
Acceptance Test Criteria
.wast
files produced by the toolchain can validate using the latest binaryen and wabt tools (see WebAssembly/binaryen and WebAssembly/WABT )