GithubHelp home page GithubHelp logo

bytecodealliance / javy Goto Github PK

View Code? Open in Web Editor NEW
2.0K 249.0 94.0 101.86 MB

JS to WebAssembly toolchain

License: Apache License 2.0

Rust 66.12% Makefile 0.60% C 2.83% JavaScript 29.89% Shell 0.06% TypeScript 0.50%

javy's Introduction

Javy

A JavaScript to Webassembly toolchain

A Bytecode Alliance project

Build status zulip chat

About this repo

Introduction: Run your JavaScript on WebAssembly. Javy takes your JavaScript code, and executes it in a WebAssembly embedded JavaScript runtime. Javy can create very small Wasm modules in the 1 to 16 KB range with use of dynamic linking. The default static linking produces modules that are at least 869 KB in size.

Runtime requirements

When running the official Javy binary on Linux, glibc 2.31 or greater must be available. You may need to update the version of your operating system if you are using an older version of glibc.

Extending Javy

If you would like to use Javy for your own project but need to make some changes, read the extending Javy documentation for one approach to consider.

Contributing

We welcome feedback, bug reports and bug fixes. We're also happy to discuss feature development but please discuss the features in an issue before contributing.

Read our contribution documentation for additional information on contributing to Javy.

Requirements to build

  • On Ubuntu, sudo apt-get install curl pkg-config libssl-dev clang
  • rustup
  • Stable Rust, installed via rustup install stable && rustup default stable
  • wasm32-wasi, can be installed via rustup target add wasm32-wasi
  • cmake, depending on your operating system and architecture, it might not be installed by default. On MacOS it can be installed with homebrew via brew install cmake. On Ubuntu, sudo apt-get install cmake.
  • Rosetta 2 if running MacOS on Apple Silicon, can be installed via softwareupdate --install-rosetta

Development requirements

  • wasmtime-cli, can be installed via cargo install wasmtime-cli (required for cargo-wasi)
  • cargo-wasi, can be installed via cargo install cargo-wasi
  • cargo-hack, can be installed via cargo +stable install cargo-hack --locked

How to build

Inside the Javy repository, run:

$ cargo build -p javy-core --target=wasm32-wasi -r
$ cargo build -p javy-cli -r

Alternatively if you want to install the Javy CLI globally, inside the Javy repository run:

$ cargo build -p javy-core --target=wasm32-wasi -r
$ cargo install --path crates/cli

If you are going to recompile frequently, you may want to prepend CARGO_PROFILE_RELEASE_LTO=off to cargo build for the CLI to speed up the build.

Using Javy

Pre-compiled binaries of the Javy CLI can be found on the releases page.

Javy supports ECMA2020 JavaScript. Javy does not provide support for NodeJS or CommonJS APIs.

Compiling to WebAssembly

Define your JavaScript like:

// Read input from stdin
const input = readInput();
// Call the function with the input
const result = foo(input);
// Write the result to stdout
writeOutput(result);

// The main function.
function foo(input) {
    return { foo: input.n + 1, newBar: input.bar + "!" };
}

// Read input from stdin
function readInput() {
    const chunkSize = 1024;
    const inputChunks = [];
    let totalBytes = 0;

    // Read all the available bytes
    while (1) {
        const buffer = new Uint8Array(chunkSize);
        // Stdin file descriptor
        const fd = 0;
        const bytesRead = Javy.IO.readSync(fd, buffer);

        totalBytes += bytesRead;
        if (bytesRead === 0) {
            break;
        }
        inputChunks.push(buffer.subarray(0, bytesRead));
    }

    // Assemble input into a single Uint8Array
    const { finalBuffer } = inputChunks.reduce((context, chunk) => {
        context.finalBuffer.set(chunk, context.bufferOffset);
        context.bufferOffset += chunk.length;
        return context;
    }, { bufferOffset: 0, finalBuffer: new Uint8Array(totalBytes) });

    return JSON.parse(new TextDecoder().decode(finalBuffer));
}

// Write output to stdout
function writeOutput(output) {
    const encodedOutput = new TextEncoder().encode(JSON.stringify(output));
    const buffer = new Uint8Array(encodedOutput);
    // Stdout file descriptor
    const fd = 1;
    Javy.IO.writeSync(fd, buffer);
}

Create a WebAssembly binary from your JavaScript by:

javy compile index.js -o destination/index.wasm

For more information on the commands you can run javy --help

You can then execute your WebAssembly binary using a WebAssembly engine:

$ echo '{ "n": 2, "bar": "baz" }' | wasmtime index.wasm
{"foo":3,"newBar":"baz!"}%   

If you have a lot of JavaScript and you want to reduce compile times, try using the --no-source-compression flag. It will skip compressing the JavaScript source code when generating the Wasm module but will result in the Wasm module being larger.

javy compile index.js -o destination/index.wasm --no-source-compression

Exporting functions

To export exported JavaScript functions, you can pass a WIT file and WIT world when running javy compile. Only ESM exports are supported (that is, Node.js/CommonJS exports are not supported). For each exported JavaScript function, Javy will add an additional function export to the WebAssembly module. Exported functions with arguments and generators are not supported. Return values will also be dropped and not returned. The Wasm module generated is a core Wasm module, not a Wasm component.

An example looks like:

index.js:

export function foo() {
  console.log("Hello from foo!");
}

console.log("Hello world!");

index.wit:

package local:main;

world index-world {
  export foo: func(); 
}

In the terminal:

$ javy compile index.js --wit index.wit -n index-world -o index.wasm
$ wasmtime run --invoke foo index.wasm
Hello world!
Hello from foo!

The WIT package name and WIT world name do not matter as long as they are present and syntactically correct WIT (that is, it needs to be two names separated by a :). The name of the WIT world (that is, the value after world and before {) must be passed as the -n argument. The -n argument identifies the WIT world in the WIT file for the Wasm module generated by javy compile.

Exports with multiple words

Exported function names with multiple words have to written in kebab-case in the WIT file (that is a restriction imposed by WIT), they are exported from the Wasm module as kebab-case to match the WIT, and Javy will match the WIT export to a JS export with the same name but in camel-case.

index.js:

export function fooBar() {
  console.log("In foo-bar");
}

index.wit:

package local:main;

world index {
  export foo-bar: func(); 
}

In the terminal:

$ javy compile index.js --wit index.wit -n index -o index.wasm
$ wasmtime run --invoke foo-bar index.wasm
In foo-bar

Exporting a default function

Exporting a function named default in the WIT world exports a function named default on the Wasm module and corresponds to either an exported default function or exported default arrow function in JS.

index.js:

export default function () {
  console.log("In default");
}

index.wit:

package local:main;

world index {
  export default: func(); 
}

In the terminal:

$ javy compile index.js --wit index.wit -n index -o index.wasm
$ wasmtime run --invoke default index.wasm
In default

You can also export a default function by writing:

export default () => {
  console.log("default");
}

Invoking Javy-generated modules programatically

Javy-generated modules are by design WASI only and follow the command pattern. Any input must be passed via stdin and any output will be placed in stdout. This is especially important when invoking Javy modules from a custom embedding.

In a runtime like Wasmtime, wasmtime-wasi can be used to set the input and retrieve the output.

Creating and using dynamically linked modules

An important use for Javy is for when you may want or need to generate much smaller Wasm modules. Using the -d flag when invoking Javy will create a dynamically linked module which will have a much smaller file size than a statically linked module. Statically linked modules embed the JS engine inside the module while dynamically linked modules rely on Wasm imports to provide the JS engine. Dynamically linked modules have special requirements that statically linked modules do not and will not execute in WebAssembly runtimes that do not meet these requirements.

To successfully instantiate and run a dynamically linked Javy module, the execution environment must provide a javy_quickjs_provider_v1 namespace for importing that links to the exports provided by the javy_quickjs_provider.wasm module. Dynamically linked modules cannot be instantiated in environments that do not provide this import.

Dynamically linked Javy modules are tied to QuickJS since they use QuickJS's bytecode representation.

Obtaining the QuickJS provider module

The javy_quickjs_provider.wasm module is available as an asset on the Javy release you are using. It can also be obtained by running javy emit-provider -o <path> to write the module into <path>.

Creating and running a dynamically linked module on the CLI

$ echo 'console.log("hello world!");' > my_code.js
$ javy compile -d -o my_code.wasm my_code.js
$ javy emit-provider -o provider.wasm
$ wasmtime run --preload javy_quickjs_provider_v1=provider.wasm my_code.wasm
hello world!

Using quickjs-wasm-rs to build your own toolchain

The quickjs-wasm-rs crate that is part of this project can be used as part of a Rust crate targeting Wasm to customize how that Rust crate interacts with QuickJS. This may be useful when trying to use JavaScript inside a Wasm module and Javy does not fit your needs as quickjs-wasm-rs contains serializers that make it easier to send structured data (for example, strings or objects) between host code and Wasm code.

Releasing

  1. Update the root Cargo.toml with the new version
  2. Create a tag for the new version like v0.2.0
git tag v0.2.0
git push origin --tags
  1. Create a new release from the new tag in github here.
  2. A GitHub Action will trigger for publish.yml when a release is published (i.e. it doesn't run on drafts), creating the artifacts for downloading.

javy's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

javy's Issues

how to execute javy inside of a wasi runtime

I noticed the make command generates a javy_core.wasm file. I assume that allows compiling javascript from within a wasi container. are there instructions for this before I spend time reverse engineering how to go about that?

Web APIs support

Would be pretty good if this tool can support Web APIs. A js file with all the necessary imports for running the wasm module should be auto-generated. I can't seem to find any js to wasm toolchain that actually supports Web APIs.

sttdef.h not found

It's seems that the header __struct_iovec.h not find the header stddef.h

When I search for it I find it in two folders:

./crates/quickjs-wasm-sys/wasi-sdk/lib/clang/11.0.0/include/stddef.h
./crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot/include/c++/v1/stddef.h

I'm on Fedora 35.

backtrace of build javy executable (I replace my path for ~):

export RUST_BACKTRACE=1 && make
cd crates/core
&& cargo build --release --target=wasm32-wasi
&& cd -
Compiling quickjs-wasm-sys v0.1.0 (/javy/crates/quickjs-wasm-sys)
The following warnings were emitted during compilation:

warning: quickjs/quickjs.c:1689:12: warning: implicit declaration of function 'malloc_usable_size' is invalid in C99 [-Wimplicit-function-declaration]
warning: return malloc_usable_size(ptr);
warning: ^
warning: quickjs/quickjs.c:10742:30: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion]
warning: else if (d > INT64_MAX)
warning: ~ ^~~~~~~~~
warning: /javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot/include/stdint.h:46:21: note: expanded from macro 'INT64_MAX'
warning: #define INT64_MAX (0x7fffffffffffffff)
warning: ^~~~~~~~~~~~~~~~~~
warning: 2 warnings generated.

error: failed to run custom build command for quickjs-wasm-sys v0.1.0 (/javy/crates/quickjs-wasm-sys)

Caused by:
process didn't exit successfully: /javy/target/release/build/quickjs-wasm-sys-19b8894d7843fb89/build-script-build (exit status: 101)
--- stdout
TARGET = Some("wasm32-wasi")
HOST = Some("x86_64-unknown-linux-gnu")
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/cutils.o" "-c" "quickjs/cutils.c"
exit status: 0
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/libbf.o" "-c" "quickjs/libbf.c"
exit status: 0
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/libregexp.o" "-c" "quickjs/libregexp.c"
exit status: 0
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/libunicode.o" "-c" "quickjs/libunicode.c"
exit status: 0
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/quickjs.o" "-c" "quickjs/quickjs.c"
cargo:warning=quickjs/quickjs.c:1689:12: warning: implicit declaration of function 'malloc_usable_size' is invalid in C99 [-Wimplicit-function-declaration]
cargo:warning= return malloc_usable_size(ptr);
cargo:warning= ^
cargo:warning=quickjs/quickjs.c:10742:30: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion]
cargo:warning= else if (d > INT64_MAX)
cargo:warning= ~ ^~~~~~~~~
cargo:warning=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot/include/stdint.h:46:21: note: expanded from macro 'INT64_MAX'
cargo:warning=#define INT64_MAX (0x7fffffffffffffff)
cargo:warning= ^~~~~~~~~~~~~~~~~~
cargo:warning=2 warnings generated.
exit status: 0
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/extensions/value.o" "-c" "extensions/value.c"
exit status: 0
AR_wasm32-wasi = None
AR_wasm32_wasi = None
TARGET_AR = None
AR = Some("/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/ar")
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/ar" "cq" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/libquickjs.a" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/cutils.o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/libbf.o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/libregexp.o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/libunicode.o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/quickjs/quickjs.o" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/extensions/value.o"
exit status: 0
running: "/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/ar" "s" "/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out/libquickjs.a"
exit status: 0
cargo:rustc-link-lib=static=quickjs
cargo:rustc-link-search=native=/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-1c06c240ac5c4496/out

--- stderr
/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot/include/__struct_iovec.h:5:10: fatal error: 'stddef.h' file not found
/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot/include/__struct_iovec.h:5:10: fatal error: 'stddef.h' file not found, err: true
thread 'main' panicked at 'called Result::unwrap() on an Err value: ()', crates/quickjs-wasm-sys/build.rs:57:10
stack backtrace:
0: rust_begin_unwind
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
2: core::result::unwrap_failed
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/result.rs:1749:5
3: core::result::Result<T,E>::unwrap
4: build_script_build::main
5: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
make: *** [Makefile:14: core] Error 101

javy & browser

Please explain me. If it is possible then how can i run wasm file in browser (can you post an full example)?

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: expected value at line 1 column 1', crates/core/src/main.rs:51:72

index.js

function main(num) {
  return num + "--";
}

var Shopify = {
  main,
};

input.json

10

This is work

echo "10" |  wasmtime run ./index.wasm  

output:
"10--"#                                                                                                                                                                                                              

But json2msgpack throws err

json2msgpack -i ./input.json | wasmtime run ./index.wasm | msgpack2json
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: EOF while parsing a value at line 2 column 0', crates/core/src/main.rs:51:72
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `./index.wasm`

Caused by:
    0: failed to invoke command default
    1: wasm trap: wasm `unreachable` instruction executed
       wasm backtrace:
           0: 0x18614 - <unknown>!<wasm function 244>
           1: 0x1a5c6 - <unknown>!<wasm function 280>
           2: 0x1a520 - <unknown>!<wasm function 279>
           3: 0x688e - <unknown>!<wasm function 74>
           4: 0x66fb - <unknown>!<wasm function 72>
           5: 0x1eb0 - <unknown>!<wasm function 35>
           6: 0xacf0 - <unknown>!<wasm function 126>
           7: 0xa109 - <unknown>!<wasm function 123>
           8: 0xbf8d4 - <unknown>!<wasm function 1165>
       
msgpack2json: parse error: mpack_error_io (2)
json2msgpack -v                                                        
json2msgpack version 0.6 -- https://github.com/ludocode/msgpack2json
RapidJSON version 1.0.2 -- http://rapidjson.org/
MPack version 0.9dev -- https://github.com/ludocode/mpack
libb64 version 1.2.1 -- http://libb64.sourceforge.net/
json2msgpack -i ./input.json | hexdump -C
00000000  0a                                                |.|
00000001

How to export functions

if there are multiple functions in a single js file, how can I export those function without spliting my source code into files?
It would be like wasmtime --invoke my_func index.wasm

quickjs-wasm-rs improvements

Rename Value and Context

As we plan to introduce an enum that represents a JSValue (see below), this rename will help us disambiguate which level of representation a type is. It also helps clarify the responsibility of the type by making it more explicit that it’s simple a Wrapper/Ref.

Renames:

  • Value -> JSValueRef
  • Context -> JSContextRef

Enum representation for JSValue

Introduce an enum that represents the underlying quickjs::JSValue

pub enum JSValue {
    Undefined,
    Null,
    Bool(bool),
    Int(i32),
    Float(f64),
    String(String),
    Array(Vec<JSValue>),
    Object(HashMap<String, JSValue>),
    MutArrayBuffer(*mut u8, usize), // used for readSync. need to hold a raw pointer to quickjs memory to write directly to
}

impl JSContextRef {
  ...
  pub fn deserialize(&self, val: &JSValueRef) -> Result<JSValue> { ... }
  pub fn serialize(&self, val: JSValue) -> Result<JSValueRef> { ... }
  ...
}

Motivations:

  1. The bindings become more ergonomic, they become truly Rust based, allowing consumers to deal only with high-level and safe Rust types.

  2. The deserialization and serialization are moved to a single place, rather than having independent serialization calls at each JS <> Rust touchpoint, which becomes error prone.

CallbackArg

Introduce a CallbackArg struct that will be used when defining callback functions. This is an optimization so that deserialization happens lazily, only if the CallbackArg is needed and used.

pub struct CallbackArg<'a> {
    inner: JSValueRef<'a>,
}

impl CallbackArg<'_> {
    pub fn value(&self) -> Result<JSValue> {
        self.value.context.deserialize(&self.inner)
    }
}


// example callback function
fn foo() -> impl FnMut(&JSContextRef, &CallbackArg, &[CallbackArg]) -> anyhow::Result<JSValue> {
    move |_: &JSContextRef, _this: &CallbackArg, args: &[CallbackArg]| {
        // deserialize args to get native Rust types
        let arg0 = args[0].value().as_i32()?;
        let arg1 = args[1].value().as_string()?;
        let arg2 = args[3].value()?.as_bool()?;
        
       // do things with args 
        ... 

        // serialize final result happens when the result gets passed back
        Ok(JSValue::String(result))
    }
}

// set function on global
global.set_property(
  "foo",
  context.wrap_callback(foo())?,
)?;

Safety: Relationship between Value and Context

This change ensures that no JSValueRef can outlive the the JSContextRef that it points to and prevent any pointers to invalid memory.

// Before
pub struct Value {
    pub(super) context: *mut JSContext,
    pub(super) value: JSValue,
}

// After
pub struct JSValueRef<'a> {
    pub(super) context: &'a JSContextRef,
    pub(super) inner: JSValue,
}

Tasks

  • Rename Value and Context
  • Implement JSValue enum and CallbackArg and use in callbacks
  • Update Value struct to contain reference to Context and add lifetimes everywhere to support this change.
  • Bump version and release

Switch back to stable toolchain once cargo wasi has been fixed

Rust 1.67 enabled bulk memory operations by default on the wasm target. cargo-wasi however does not enable the bulk memory features flag yet, causing failed builds. To remedy this, we have fixed the Rust toolchain to 1.66 for now.

Once cargo wasi has fixed their instrumentation of wasm-opt, we should switch back to stable.

can javy used to compile a nodejs project ?

i think this line is the reason throw error,

const mathjs = require('mathjs');

so the javy can not used to compile a nodejs project ?

the errors is below:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Uncaught ReferenceError: 'require' is not defined
at (function.mjs:1)
', crates/core/src/main.rs:40:5
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Error: failed to run main module index.wasm

Caused by:
0: failed to invoke command default
1: error while executing at wasm backtrace:
0: 0x112d1 - !<wasm function 278>
1: 0x10a99 - !<wasm function 277>
2: 0x109e5 - !<wasm function 276>
3: 0x35c4 - !<wasm function 74>
4: 0x131b - !<wasm function 39>
5: 0x23d6 - !<wasm function 55>
6: 0xab5b - !<wasm function 168>
7: 0xa9ca - !<wasm function 167>
8: 0xb557a - !<wasm function 1125>
2: wasm trap: wasm unreachable instruction executed

Investigate why updating bindgen to a version newer than 0.60 doesn't emit some bindings

After trying to update bindings in quickjs-wasm-rs to 0.61 or newer, I get:

error[E0432]: unresolved import `quickjs_wasm_sys::size_t`
 --> crates/quickjs-wasm-rs/src/js_binding/value.rs:6:5
  |
6 |     size_t as JS_size_t, JSContext, JSValue, JS_BigIntSigned, JS_BigIntToInt64, JS_BigIntToUint64,
  |     ------^^^^^^^^^^^^^
  |     |
  |     no `size_t` in the root
  |     help: a similar name exists in the module: `time_t`

We should probably figure out what's going on so we can continue updating.

No wasm file after running shopify app function build

Operating system: Ubuntu 18.04

Javy version: 0.6

Shopify CLI: 3.45.1

Problem

I'm following step 1 of this tutorial and I select Javascript as the language to be used. When I run npm run deploy, it gives me an error:

╭─ error ─────────────────────────────────────────────────────────────────────────
│ │
│ The following function extensions haven't compiled the wasm in the expected path: │
│ · cart-checkout-validation: extensions/cart-checkout-validation/dist/function.wasm │
│ │
│ │
│ Make sure the build command outputs the wasm in the expected directory.

In the dist folder, I can only find the function.js file. So I try to run npm run shopify app function build -- --path extensions/cart-checkout-validation/ to generate the wasm file with the function.js. But there is no wasm file after running this command. It gives me:

Running javy ...
/home/bennychan/.cache/binarycache/javy-v0.6.0: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.26' not found (required by /home/bennychan/.cache/binarycache/javy-v0.6.0)
/home/bennychan/.cache/binarycache/javy-v0.6.0: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.28' not found (required by /home/bennychan/.cache/binaycache/javy-v0.6.0)
/home/bennychan/.cache/binarycache/javy-v0.6.0: /lib/x86_64-linux-gnu/libc.s
╭─ success ────────────────────────────────────────────────────────────────╮
│ │
│ Function built successfully. │

I try to run sudo apt install libstdc++6. But it gives me libstdc++6 is already the newest version (8.4.0-1ubuntu1~18.04).

Update:
I've found that GLIBCXX_3.4.26 is not available on Ubuntu 18.04. Upgrade the OS to 20.04 and it's alright now

Uncaught SyntaxError: invalid escape sequence in regular expression

While experimenting with a solution that uses javy, I happened to include the camelcase package. When attempting to build, I get the error below.

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Uncaught SyntaxError: invalid escape sequence in regular expression
    at RegExp (native)
    at <eval> (<input>:10)
    at ./node_modules/camelcase/index.js (script.js:39)
    at __webpack_require__ (script.js:63)
    at <eval> (<input>:2)
    at ./src/index.js (script.js:29)
    at __webpack_require__ (script.js:63)
    at <anonymous> (script.js:115)
    at <anonymous> (script.js:118)
    at webpackUniversalModuleDefinition (script.js:15)
    at <eval> (script.js:120)
', crates/core/src/lib.rs:35:61
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: the `wizer.initialize` function trapped

Caused by:
    wasm trap: wasm `unreachable` instruction executed
    wasm backtrace:
        0: 0xcb9d9 - <unknown>!__rust_start_panic
    note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable to may show more debugging information

Error: Couldn't create wasm from input

Reproduction here, I was able to isolate the issue to the following lines in camelcase:

const IDENTIFIER = /([\p{Alpha}\p{N}_]|$)/u;
const SEPARATORS = /[_.\- ]+/;
const LEADING_SEPARATORS = new RegExp('^' + SEPARATORS.source);

// THIS LINE APPEARS TO BE THE ISSUE
const SEPARATORS_AND_IDENTIFIER = new RegExp(SEPARATORS.source + IDENTIFIER.source, 'gu');

Not sure what the exact issue is, or how common it might be in other code.

JSON input keys with underscores renamed to camel case

With javy-arm-macos-v0.3.0.gz release and wasmtime 0.40.1 I am seeing the input json keys with underscores being mangled:

// test.js
function main(input) {
  return JSON.stringify(input);
}
Shopify = { main };
% javy test.js -o test.wasm
warning: unknown name subsection with id 9 at 1397405
% echo '{"hello_world":1}' | wasmtime run test.wasm
"{\"helloWorld\":1}"

Extract generic components and add support for binding generation

Goal : Align on the potential avenues to enable Javy's codebase to serve arbitrary use cases.

The proposed solutions should

  • Keep compatibility with module snapshotting through Wizer
  • Allow composing JavaScript modules through module linking (more concretely the Component Model)
  • Provide an interface to the underlying JavaScript that allows:
    • Allocating and freeing memory, as described in the Canonical ABI
    • Binding generation for Interface Types (á la wit-bindgen)
  • Provide a way to configure multiple data serialization mechanisms (i.e. using messagepack instead of relying on interface types)
  • Not define platform specific behavior. The solution should focus only on providing the necessary building blocks as dependencies so that consumers can import those building blocks to build custom solutions.

Proposed (high level) changes

  1. Publish the quickjs_sys crate as a standalone crate
  2. Remove platform specific behavior from the core crate
    • Custom function entrypoints
    • Factor out the messagepack serialization part into its own crate (i.e. javy_messagepack)
    • Remove crate-type = cdylib, should be a normal lib crate
  3. Add the missing JS_* interfaces in the core crate that will help in Interface Types binding generation.
  4. Introduce a new crate responsible for interface types binding generation (i.e. javy_bindgen / quickjs_bindgen)

Usage

With interface types

In a bindgen-based scenario, a rough sketch of the usage would be:

// In a custom lib.rs

use javy_bindgen::import!("path/imports.wit"); // (1)
use javy_core::Context; // (2)

let import_obj = Context::new_object()?;

imports::bind(&context, &import_obj); // (3)

(1) Generate code for imports (defining a wrapper around the host export, lowering parameters, lifting return values). Similar thing will be done for exports.

(2) javy_bindgen will depend on javy_core; a given consumer could depend directly on javy_core or javy_bindgen could re-export the API from javy_core. (This is TBD)

(3) The consumer must explicitly call the setup code

With a different serialization mechanism

In a messagepack-based scenario, a rough sketch of usage would be:

use javy_messagepack::{to_js_value, to_bytes};
use javy_core::Context;

let input = to_js_value(&context, &bytes).unwrap();
let output  = to_bytes(&output_value.unwrap()).unwrap();

Open questions/tradeoffs/thoughts

  • Regarding the CLI: with the proposed changes and approach, the CLI crate becomes irrelevant IMO in the context of reusability, given that each consumer is responsible for creating a project and for putting each of the pieces together depending on each use case, following that line of thought, each consumer/use case will be responsible for providing their own CLI implementation. Thoughts?

  • Regarding binding generation for exports/imports: I took Suborbital's base implementation1 as a reference, and therefore this proposal operates under the assumption that import and export generation will always be static (at compile time) and always made completely available to the JS source code, I could see a possibility where the generation should be done in a more dynamic way, in which the consumer specifies a subset of the functionality that they'd like to import, but I'm not sure if: (i) that's a realistic use case (ii) such use case should be considered as part of this proposal (iii) the feasibility of such use case.

  • Is there anything else that should be included? Excluded?

Footnotes

  1. https://github.com/suborbital/javy/pull/3

CMake is undocumented dependency for local build

I was unable to successfully run make without installing CMake:

error: failed to run custom build command for `binaryen-sys v0.12.0`

Caused by:
  process didn't exit successfully: `/Users/nickwesselman/src/javy/target/release/build/binaryen-sys-fd3d87b2d3e0fe08/build-script-build` (exit status: 101)
  --- stdout
  running: "cmake" "/Users/nickwesselman/.cargo/registry/src/github.com-1ecc6299db9ec823/binaryen-sys-0.12.0/binaryen" "-DBUILD_STATIC_LIB=ON" "-DENABLE_WERROR=OFF" "-DCMAKE_INSTALL_PREFIX=/Users/nickwesselman/src/javy/target/release/build/binaryen-sys-1ef0729e257a20ee/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release"

  --- stderr
  fatal: not a git repository (or any of the parent directories): .git
  thread 'main' panicked at '
  failed to execute command: No such file or directory (os error 2)
  is `cmake` not installed?

  build script failed, must exit now', /Users/nickwesselman/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.45/src/lib.rs:894:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Should this be documented in the README? Happy to PR if so.

How to add dependencies

I have following dependencies in my .js file:

const fs = require('fs');
const parser = require('@asyncapi/parser');
const process = require("process");
const path = require('path');

on running javy helper.js -o index.wasm it is giving me this error

thread '' panicked at 'called Result::unwrap() on an Err value: Uncaught ReferenceError: 'require' is not defined
at (script.js:1)
', crates/core/src/main.rs:33:61
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Error: the wizer.initialize function trapped

Can anyone help me how to add dependency into .wasm?

reduce binary size of 1MB to 250kb

Hi,

Trying to deploy to Shopify functions a wasm built with javy:

  The size of the Wasm binary file for Function is too large. It must be less than 256 KB.

How would you recommend to proceed?

Saw related work: #56
Are there other plans?

Random seems broken in Javy

Given a JS source file that looks like:

console.log(Math.random())

I see the following output:

➜  javy git:(main) target/release/javy compile index.js -o index.wasm                                                                   
➜  javy git:(main) wasmtime run index.wasm
0.6111985957948094
➜  javy git:(main) wasmtime run index.wasm
0.6111985957948094

Running the same module with a random call multiple times results in the same output. Random should not be deterministic when not using a deterministic-wasi-ctx.

New crates to support reusing API implementations

Summary of changes

We'll be:

  • adding a javy crate that exposes a Runtime and Config that wraps JSContextRef with the ability to access the underlying JSContextRef (this may be revisited in a future iteration
  • adding an apis crate that contains reusable implementations for console, TextEncoder, TextDecoder, Javy.IO.readSync, and Javy.IO.writeSync that can be added to a Runtime

Motivations

We want to have an easier to understand API for configuring and managing the JS environment used within Javy. We also want other developers building on top of Javy to be able to reuse our implementations of console, TextEncoder, TextDecoder, Javy.IO.readSync, and Javy.IO.writeSync if they want to and for it to be relatively straightforward.

Tasks

  • Add javy crate with Runtime and Config
  • Add apis crate with all of the implementations above
  • Publish crates to crates.io

Shopify Functions - M1 Mac Pro Javy UnhandledPromiseRejectionWarning

I am currently following the guide here starting with step 1. Before step 8, I try and run "npm run build" to compile my function (written in JS), but I'm greeted with the following error:

Running javy ...
(node:27385) UnhandledPromiseRejectionWarning: TypeError: resp.headers.get(...).split(...).at is not a function
at getDesiredVersionNumber (file:///Users/user/Documents/Projects/shop-functions/node_modules/javy-cli/index.js:96:49)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async main (file:///Users/user/Documents/Projects/shop-functions/node_modules/javy-cli/index.js:15:18)
(Use node --trace-warnings ... to show where the warning was created)
(node:27385) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)


Which refers to this function
/**

  • getDesiredVersionNumber returns the version number of the release that
  • should be downloaded and launched. If the FORCE_RELEASE env variable is set,
  • that will be used as the desired version number, if not, we determine the
  • latest release available on GitHub.
  • GitHub has a public Release API, but rate limits it per IP, so that the
  • CLI can end up breaking. Instead, we use a little trick. You can download
  • artifacts from the latest release by using latest as your version number.
  • The server will respond with a 302 redirect to the artifact's URL. That URL
  • contains the actual release version number, which we can extract.
    */
    async function getDesiredVersionNumber() {
    if (process.env.FORCE_RELEASE) return process.env.FORCE_RELEASE;
    const resp = await fetch(
    https://github.com/${REPO}/releases/latest/download/lol,
    { redirect: "manual" }
    );
    if (resp.status != 302) {
    throw Error(
    Could not determine latest release using the GitHub (Status code ${resp.status }): ${await resp.text().catch(() => "<No error message>")}
    );
    }
    return resp.headers.get("location").split("/").at(-2);
    }

Just trying to debug and see why this could be happening, and whether or not it's dependent upon my OS as I'm fairly new to this topic.

Current setup:
Apple M1 Pro, macOS Monterey 12.3.1
NPM: 7.24.2
Node: 14.18.0
App is using a node template, function is in JS

cannot compile javascript to wasm

i am trying to convert my javascript file to .wasm but getting this error can you have any idea after viewing this error?

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Uncaught ReferenceError: 'require' is not defined
    at <eval> (script.js:1)
', crates/core/src/main.rs:33:61
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: the `wizer.initialize` function trapped

Caused by:
    wasm trap: wasm `unreachable` instruction executed
    wasm backtrace:
        0: 0x1fbba - <unknown>!rust_panic
        1: 0x15370 - <unknown>!std::panicking::rust_panic_with_hook::hd67762ecc8bae640
        2: 0x200cb - <unknown>!std::panicking::begin_panic_handler::{{closure}}::h4aed573334d346d1
        3: 0x20016 - <unknown>!std::sys_common::backtrace::__rust_end_short_backtrace::h33c000da160739e7
        4: 0x7d07 - <unknown>!rust_begin_unwind
        5: 0x1755 - <unknown>!core::panicking::panic_fmt::hddd782b3234e7a63
        6: 0x26a4 - <unknown>!core::result::unwrap_failed::h70df1603dbe85f50
        7: 0xb17b - <unknown>!wizer.initialize
        8: 0xd97c6 - <unknown>!wizer.initialize.command_export
    note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable to may show more debugging information

How does Javy support Node.js & NPM modules?

Usually JS script requires other npm modules. Is Javy able to compile them together? I tried to have code require("firebase-admin/app") to use firebase sdk in my code but it's not working.

<wasi/api.h> is only supported on WASI platforms

build error on MacOS (Intel): <wasi/api.h> is only supported on WASI platforms
I am guessing that this has something to do with stdio. (cmake was installed successfully using homebres).
I'm stuck with it, since I haven't practiced C programming the last 20 years.

Execute wasm binary file generated by javy in HTML

I have created a webAssembly binary file from simple javascript file by javy.

But I am unable to execute this webAssembly binary file in my html file. Kindly suggest me how to proceed.

simple javascript file - add.js

export function add(a,b){
	return a + b;
}

Generated wasm file by following command

javy compile add.js -o add.wasm

Now I am trying to load this wasm file

fetch('add.wasm')
  .then(response => response.arrayBuffer())
  .then(bytes => WebAssembly.instantiate(bytes))
  .then(result => {
    // Call a function in the WebAssembly module
    const add = result.instance.exports.add;
    console.log(add(2, 3.5)); // Output: 5.5
  });

But it throws error like
Uncaught (in promise) TypeError: WebAssembly.instantiate(): Imports argument must be present and must be an object

Help me if I missed something

Host Functions

What is your question?

How can I call a host (imported) function from within a javascript application compiled with javy?

Details

First of all, great work on Javy! It's really awesome what ya'll are building.

Pulling out the quickjs runtime into a separate dynamic module is a great idea. It's a lot of overhead to ship an entire interpreter or runtime with every wasm program when it's going to be the same code every time (other than the user's code).

One thing I'm not clear on with Javy is how to call host (imported) functions. I believe calling code outside of the WASM module is already being done via the dynamic linker, but it seems to be calling wasm <=> wasm, rather than from wasm => host.

For example, if I am running wasmtime embedded within a Go application - how can I have the javascript code running inside the quickjs runtime (with or without dynamic linking) invoke a Go method and get the response back into the javascript execution environment?

I believe WASI is implemented basically the same as host functions, but the signature of WASI is known ahead-of-time, so I'm guessing that WASI's structure is hardcoded into the javy compiler, as are the function signatures used for the runtime linking. Is that right, and if so, is there a way to build the code so that it relies on an import that doesn't exist during compile time, but only during execution time?

Thanks in advance, and great work on Javy!

Unexpected non-deterministic output when recompiling Javy provider

Given a JS file that has the following source code:

console.log(Math.random())

I see the following results:

➜  javy git:(main) target/release/javy compile -d index.js -o index.wasm                                                                   
➜  javy git:(main) wasmtime run --preload javy_quickjs_provider_v1=target/wasm32-wasi/release/javy_quickjs_provider_wizened.wasm index.wasm
0.6111985957948094
➜  javy git:(main) wasmtime run --preload javy_quickjs_provider_v1=target/wasm32-wasi/release/javy_quickjs_provider_wizened.wasm index.wasm
0.6111985957948094
➜  javy git:(main) make core
cargo build --package=javy-core --release --target=wasm32-wasi --features=
    Finished release [optimized] target(s) in 0.09s
wizer target/wasm32-wasi/release/javy_quickjs_provider.wasm --allow-wasi --wasm-bulk-memory true -o target/wasm32-wasi/release/javy_quickjs_provider_wizened.wasm
➜  javy git:(main) wasmtime run --preload javy_quickjs_provider_v1=target/wasm32-wasi/release/javy_quickjs_provider_wizened.wasm index.wasm
0.3228588863524102
➜  javy git:(main) wasmtime run --preload javy_quickjs_provider_v1=target/wasm32-wasi/release/javy_quickjs_provider_wizened.wasm index.wasm
0.3228588863524102

Running the same module with the same provider twice has identical output. This is expected for Shopify Functions. I've filed #318 for the non-Shopify use case since this is unexpected for that. However, simply recompiling the provider and linking to the recompiled provider, and then re-running the same module results in a different output. If there were a code change in the provider code, this would be somewhat expected. But there is no change which makes this unexpected behaviour to me and possibly for a Shopify Functions developer.

An additional impact of this bug is that our builds are non-deterministic. Rebuilding with the same code will always yield a slightly different executable which makes investigating some issues more difficult.

Why clis?

I noticed these two entries in the README

wasmtime-cli, can be installed via cargo install wasmtime-cli
cargo-wasi, can be installed via cargo install cargo-wasi

They don't seem to be used, what are they for?

`parse errror` while trying to deploy WebAssembly Binary on Wasmtime

Hi,

I am successfully able to generate my WebAssembly Binary but when I am trying to deploy it on Wasmtime:

json2msgpack -i input.json | wasmtime run binary.wasm | msgpack2json

I am consistently getting this error:
Screenshot 2022-05-06 at 12 45 29 PM

Things are working fine on my System, but I was trying to reproduce it on some another system and I am getting this error.

Installed Toolchains:
Screenshot 2022-05-06 at 12 47 00 PM

How to compile quickjs_wasm_rs and quick_wasm_sys as non-wasm targets

I'm trying to build a JavaScript FaaS system, but I noticed that the performance is not very high after using wasm, I want to build Rust-quickjs as a binary directly based on the quickjs_wasm_rs module, but when I modify the build.rs file of quickjs_wasm_sys it doesn't work well. Please tell me how to modify it to make it work?

QuickJS is not compiled to WASM

I couldn't find a reference to Emscripten, so I assume QuickJS is currently not compiled to WASM.

WASM is simply calling JS_Eval, and then the JS code is compiled and evaluated outside of WASM's memory. Is this correct?

If so, doesn't this defeat the purpose of using WASM, and opt us out of any security benefits provided by WASM?

Shouldn't we compile QuickJS to WASM, throught Emscripten, and execute the JS inside the WASM VM?

Am I missing something here?

Promises non handled

I have a javascript code that uses promises (in my specific case a library that parses XML) and runs smoothly when run with quickjs, but when run thrugh javy and then run with wasmtime it does not run. I then tested a small script with just a simple promise that resolves immediatly but the code does not run.
Bottomline: are promises handled ? is there some change I must add to a code with promises to run correctly ?

Calling wasm modules compiled by javy

I've been playing around with the examples for javy, in particular the one in the readme:

function foo(input) {
    return { foo: input.n + 1, newBar: input.bar + "!" };
}

Shopify = {
    main: foo,
};

Using wasmer from the cli, it easy to pass in a string to the main function: echo '{ "n": 2, "bar": "baz" }' | wasmer shopify.wasm

Inspecting the compiled file, I can see the following exported functions:

Type: wasm
Size: 999.3 KB
Imports:
  Functions:
    "wasi_snapshot_preview1"."fd_write": [I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_read": [I32, I32, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."clock_time_get": [I32, I64, I32] -> [I32]
    "wasi_snapshot_preview1"."proc_exit": [I32] -> []
    "wasi_snapshot_preview1"."environ_sizes_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."environ_get": [I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_seek": [I32, I64, I32, I32] -> [I32]
    "wasi_snapshot_preview1"."fd_close": [I32] -> [I32]
    "wasi_snapshot_preview1"."fd_fdstat_get": [I32, I32] -> [I32]
  Memories:
  Tables:
  Globals:
Exports:
  Functions:
    "_start": [] -> []
    "main": [I32, I32] -> [I32]
  Memories:
    "memory": not shared (22 pages..)
  Tables:
  Globals:
    "__heap_base": I32 (constant)
    "__data_end": I32 (constant)

I want to call the module from go. In order to pass in a string, I need to allocate memory (example here: https://github.com/tetratelabs/wazero/blob/main/examples/allocation/tinygo/greet.go#L67). The function signature for main "main": [I32, I32] -> [I32] looks like it takes a pointer to memory and a length.

Since the module compiled by javy does not have malloc or free functions exported, how can this be done?
How is wasmer able to call the module with a string?

Ref: tetratelabs/wazero#591 and tetratelabs/wazero#592

Is the javascript still interpreted?

Hi I am sorry if this is a repeated question.

Does this project run an interpreted version of JS in WASM environment? like quickjs (qjsc) -> byte code -> executed in a quickjs interpreter, where the interpreter itself compiled to WASM? or there are optimizations done to the JS code and actually converted WASM?

Thanks

Problem with anyhow

/home/veljko/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.55/src/error.rs:617:14
|
617 | ptr::addr_of!((*unerased.as_ptr())._object) as *mut E,
| ^^^^^^^ could not find addr_of in ptr

when running make command in the root directory I am getting this error

error: failed to run custom build command for quickjs-wasm-sys v0.1.0 (/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys)

Caused by:
process didn't exit successfully: /home/jaikitjilka/projects/javy/target/release/build/quickjs-wasm-sys-b6dd2061dcd0d73c/build-script-build (exit status: 101)
--- stdout
TARGET = Some("wasm32-wasi")
HOST = Some("x86_64-unknown-linux-gnu")
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
CC_wasm32-wasi = None
CC_wasm32_wasi = None
TARGET_CC = None
CC = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang")
CFLAGS_wasm32-wasi = None
CFLAGS_wasm32_wasi = None
TARGET_CFLAGS = None
CFLAGS = Some("--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot")
CRATE_CC_NO_DEFAULTS = None
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/cutils.o" "-c" "quickjs/cutils.c"
exit status: 0
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/libbf.o" "-c" "quickjs/libbf.c"
exit status: 0
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/libregexp.o" "-c" "quickjs/libregexp.c"
exit status: 0
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/libunicode.o" "-c" "quickjs/libunicode.c"
exit status: 0
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/quickjs.o" "-c" "quickjs/quickjs.c"
cargo:warning=quickjs/quickjs.c:1689:12: warning: implicit declaration of function 'malloc_usable_size' is invalid in C99 [-Wimplicit-function-declaration]
cargo:warning= return malloc_usable_size(ptr);
cargo:warning= ^
cargo:warning=quickjs/quickjs.c:10742:30: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion]
cargo:warning= else if (d > INT64_MAX)
cargo:warning= ~ ^~~~~~~~~
cargo:warning=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot/include/stdint.h:46:21: note: expanded from macro 'INT64_MAX'
cargo:warning=#define INT64_MAX (0x7fffffffffffffff)
cargo:warning= ^~~~~~~~~~~~~~~~~~
cargo:warning=2 warnings generated.
exit status: 0
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-wasi" "--sysroot=/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/share/wasi-sysroot" "-Wchar-subscripts" "-Wno-array-bounds" "-Wno-missing-field-initializers" "-Wno-sign-compare" "-Wno-unused-parameter" "-Wundef" "-Wuninitialized" "-Wunused" "-Wwrite-strings" "-funsigned-char" "-Wno-implicit-fallthrough" "-Wno-enum-conversion" "-D_GNU_SOURCE" "-DCONFIG_VERSION="2021-03-27"" "-DCONFIG_BIGNUM" "-o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/extensions/value.o" "-c" "extensions/value.c"
exit status: 0
AR_wasm32-wasi = None
AR_wasm32_wasi = None
TARGET_AR = None
AR = Some("/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/ar")
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/ar" "cq" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/libquickjs.a" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/cutils.o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/libbf.o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/libregexp.o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/libunicode.o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/quickjs/quickjs.o" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/extensions/value.o"
exit status: 0
running: "/home/jaikitjilka/projects/javy/crates/quickjs-wasm-sys/wasi-sdk/bin/ar" "s" "/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out/libquickjs.a"
exit status: 0
cargo:rustc-link-lib=static=quickjs
cargo:rustc-link-search=native=/home/jaikitjilka/projects/javy/target/wasm32-wasi/release/build/quickjs-wasm-sys-29473bfbb0f3c7be/out

--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-.so', 'libclang.so.', 'libclang-.so.'], set the LIBCLANG_PATH environment variable to a path where one of these files can be found (invalid: [])"', /home/jaikitjilka/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.59.2/src/lib.rs:2144:31
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
make: *** [Makefile:14: core] Error 101

question about the working mechasnim

Hi, this is a very interesting project. I saw the approach a few times to compile QUICKJS into the wasm module and run the JS from the Wasm module.

This project says it will compile the JS into Wasm module. I just wonder how it will handle the dynamic properties in a JS object and other JS language features?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.