Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Toolchain produces out-of-date WAST format #2187

Closed
1 task
wanderingbort opened this issue Apr 6, 2018 · 6 comments
Closed
1 task

Toolchain produces out-of-date WAST format #2187

wanderingbort opened this issue Apr 6, 2018 · 6 comments
Milestone

Comments

@wanderingbort
Copy link
Contributor

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 of s2wasm 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 )
@gleehokie gleehokie added this to the RC2 milestone Apr 6, 2018
@spoonincode
Copy link
Contributor

Note that one of the new requirements is for our toolchain to output binary WASM. That kind of makes this issue irrelevant.

@jcalfee
Copy link
Contributor

jcalfee commented Apr 25, 2018

Note: In the issue EOSIO/eosjs#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..

@abourget
Copy link
Contributor

abourget commented May 4, 2018

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 ?

@spoonincode
Copy link
Contributor

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.

@spoonincode spoonincode removed their assignment May 7, 2018
@bytemaster bytemaster modified the milestones: RC2, Verison 1.1 May 9, 2018
@spoonincode
Copy link
Contributor

No ATC needed; unit tests should have this well covered that we didn't break something

@plazav
Copy link

plazav commented Aug 2, 2018

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
      })

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants