I couldn't resist trying to run this in between meetings. :p

PS C:\Users\micro\Documents\GitHub\wasm> dart --version
Dart SDK version: 2.14.0-182.0.dev (dev) (Thu Jun 3 16:01:27 2021 -0700) on "windows_x64"

[√] Flutter (Channel master, 2.3.0-17.0.pre.220, on Microsoft Windows [Version 10.0.19041.985], locale en-US)
    • Flutter version 2.3.0-17.0.pre.220 at C:\Users\micro\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2f88966935 (75 minutes ago), 2021-06-04 13:58:21 -0700
    • Engine revision 03d645e782
    • Dart version 2.14.0 (build 2.14.0-182.0.dev)

PS C:\Users\micro\Documents\GitHub\wasm> dart pub get
Resolving dependencies...
  analyzer 1.7.0 (1.7.1 available)
Got dependencies!
PS C:\Users\micro\Documents\GitHub\wasm> dart run wasm:setup      
Unhandled exception:
Invalid argument(s): Could not find ".dart_tool/package_config.json" within "file:///C:/Users/micro/Documents/GitHub/wasm/".
#0      _getOutDir (file:///C:/Users/micro/Documents/GitHub/wasm/bin/setup.dart:64:5)
#1      _main (file:///C:/Users/micro/Documents/GitHub/wasm/bin/setup.dart:118:18)
#2      main (file:///C:/Users/micro/Documents/GitHub/wasm/bin/setup.dart:25:11)
<asynchronous suspension>

Although there is a comment in the code (_getLibName) suggesting windows support may not be implemented yet, so maybe this is expected.

Please feel free to disregard if this is not helpful. I just was curious to play with the fancy new code, that's all. Maybe I'll find some time on a weekend to hack on it a bit.

It's necessary to run package:wasm's setup.dart script when using package:flutter_wasm, but pub says "Cannot run executables in transitive dependencies.". So in the documentation users are told to depend on package:wasm as well as package:flutter_wasm. This is not ideal.

It would be better to include setup.dart in flutter_wasm. It would be nice to figure out a way to avoid code duplication, but export 'package:wasm/bin/setup.dart'; doesn't work because that path is relative to wasm/lib/, so it can't get to the bin directory.

When run code with flutter on Android arm64-v8a:

import 'package:wasm/wasm.dart';

var mod = WasmModule(m);
var inst = mod.builder().build();  // error here

got this error:

E/flutter (10982): WasmError: Wasm module instantiation failed.
E/flutter (10982): missing requires CPU features: "EnumSet(SSE2)"
E/flutter (10982): #0      WasmRuntime._checkNotEqual (package:wasm/src/runtime.g.dart:952:7)
E/flutter (10982): #1      WasmRuntime.instantiate (package:wasm/src/runtime.g.dart:713:5)
E/flutter (10982): #2      new WasmInstance._ (package:wasm/src/module.dart:261:25)
E/flutter (10982): #3      WasmInstanceBuilder.build (package:wasm/src/module.dart:228:25)

The reason is this code: https://github.com/dart-lang/wasm/blob/0789947186747fad02d01f5e858b049f09b8cd81/wasm/lib/src/runtime.g.dart#L579

  Pointer<WasmerConfig> _createEngineConfig() {
    final config = _config_new();
    final triple = _wasmer_triple_new_from_host();
    final cpuFeatures = _wasmer_cpu_features_new();
    final sse2 = _allocateString('sse2');
    _wasmer_cpu_features_add(cpuFeatures, sse2);
    calloc.free(sse2.ref.data);
    calloc.free(sse2);
    final target = _wasmer_target_new(triple, cpuFeatures);
    _config_set_target(config, target);
    return config;
  }

after remove _wasmer_cpu_features_add(cpuFeatures, sse2); everything works fine ;-)

• flutter version: 2.8.1 (stable)

This moves the runtime singleton into the higher level API so we can hide it, and removes it from the unrelated lower level wasmer bindings where it isn't necessary.

I think I have a clean solution for #47 that will also allow us to test for wasmer related memory leaks and fix that one place that leaks memory where the import isn't being disposed of. @liamappelbe could you recommend me a workflow to submit multiple PRs that depend on eachother in a way that would make it easy for you to review them and allow us to move faster?

This is one of the feature requests from #38

This change should be transparent to users at this stage, but will enable future features like sharing memory or functions between modules.

Hi! Thanks for your work!

I was receiving the error message WasmError: This case is not (yet) supported. Please file an issue on pkg:wasmwhen trying out the package.

You can run the test in https://github.com/juancastillo0/dart-parser/blob/main/test/parser_test.dart to receive the same error. The wasm file was generated using wasm-pack build for the Rust project in the dart-parser-wasm folder of the same repository. It uses wasm-pack and wasm-bidgen.

WasmError: This case is not (yet) supported. Please file an issue on pkg:wasm.
WasmRuntime.maybeThrowTrap
package:wasm/src/runtime.g.dart:610
WasmRuntime.call
package:wasm/src/runtime.g.dart:680
WasmFunction.apply
package:wasm/src/module.dart:403
_Instance.lookupFunction.<fn>
package:dart_fixer_test/…/wasm/wasm_interop_native.dart:108
DartParserWasmModule.parse
package:dart_fixer_test/…/wasm/dart_parser_wasm_bg.dart:122
DartParser.parse
package:dart_fixer_test/wasm/dart_parser_wasm.dart:44
main.<fn>

The same error was also happening when trying some models in https://github.com/juancastillo0/tensorflow_dart.

Please let me know if there is something else I can do. I could try to make a PR.

Thanks!

See #92 step 2.

The following are some TODOs as a note to myself:

• the circular dependency between runtime.compile and WasmModule should be broken by having the owner be a function that receives the pointer and returns an owner and a generic return type.
• the async version for constructing a WasmModule is not doing anything that the sync version isn't doing and could be removed. It seems to act as a reminder for providing an async construction scheme in the future?

The parallel programming facilities in Dart do not support shared memory parallelism. Any computation that can't block the main isolate needs to run in a different isolate where exchange of data can only happen through message passing. This is safe, but restricting. In general, message passing between isolates isn't free and there are data structures (e.g. the fat node approach for Persistent Data Structures) that can't be efficiently implemented (or simulated) with message passing only.

One workaround is to allocate memory not on the dart heap, but natively via ffi. Pointers to that natively allocated memory can be shared between isolates and shared memory parallelism can be simulated that way.

The wasmer bindings shouldn't necessarily focus on solving this use case, but they shouldn't prohibit making use of the workaround mentioned above. We should allow for that by being general enough and provide at least the facilities to allow for the following:

• manual memory management (e.g. by providing a way to use wasmer without having to use finalizers for memory management)
• manual memory allocation (e.g. by not forcing users to use dart:typed_data for memory allocation)

I plan to investigate this, and I think it can be achieved by:

• having explicit wasmer bindings in the style of #92 without finalizers and with a delegate for injecting a custom memory allocator.
• an adapter between the wasm_api.dart from #92 and the wasmer bindings. This adapter could use #95 for memory management and dart:typed_data for memory allocation.

Context #95 After this change, the build step for wasmer should reduce to building the wasmer library only. Creating bindings for ios, android and so on should therefore become significantly simpler.

@liamappelbe what do you think? I haven't used this API yet personally, but it seems like it was built for this purpose and is probably a wrapper around the same API that you were using natively.

Tried it on linux without an issue.

Mac @ Dart 2.12 https://github.com/dart-lang/wasm/pull/12/checks?check_run_id=2750754609#step:7:568

Mac @ Dart SDK version: 2.14.0-176.0.dev (dev) (Wed Jun 2 15:17:55 2021 -0700) on "macos_x64" https://github.com/dart-lang/wasm/pull/12/checks?check_run_id=2750754624#step:7:190

Here's a repro.

// Copyright (c) 2021, the Dart project authors.  Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

// Test throwing exceptions from an imported function.
import 'dart:typed_data';

import 'package:wasm/wasm.dart';

void main() {
  var data = Uint8List.fromList([
    0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00, 0x01, 0x04, 0x01, 0x60, //
    0x00, 0x00, 0x02, 0x11, 0x02, 0x03, 0x65, 0x6e, 0x76, 0x01, 0x61, 0x00,
    0x00, 0x03, 0x65, 0x6e, 0x76, 0x01, 0x62, 0x00, 0x00, 0x03, 0x02, 0x01,
    0x00, 0x04, 0x05, 0x01, 0x70, 0x01, 0x01, 0x01, 0x05, 0x03, 0x01, 0x00,
    0x02, 0x06, 0x08, 0x01, 0x7f, 0x01, 0x41, 0x80, 0x88, 0x04, 0x0b, 0x07,
    0x0f, 0x02, 0x06, 0x6d, 0x65, 0x6d, 0x6f, 0x72, 0x79, 0x02, 0x00, 0x02,
    0x66, 0x6e, 0x00, 0x02, 0x0a, 0x10, 0x01, 0x0e, 0x00, 0x10, 0x80, 0x80,
    0x80, 0x80, 0x00, 0x10, 0x81, 0x80, 0x80, 0x80, 0x00, 0x0b,
  ]);

  var thrownException = Exception('Hello exception!');

  var errorCount = 0;
  for (var i = 0; true; i++) {
    var builder = (WasmModule(data).builder()
      ..addFunction('env', 'a', () {
        throw thrownException;
      })
      ..addFunction('env', 'b', () {
        throw StateError('should not get here!');
      }));

    var inst = builder.build();

    var fn = inst.lookupFunction('fn');

    try {
      fn();
    } on Exception {
      // noop
    } catch (e, stack) {
      print(e);
      print(stack);
      errorCount++;

      if (errorCount > 10) {
        break;
      }
    }
    print([errorCount, i]);
  }
}

https://github.com/dart-lang/wasm/actions/runs/2178344056

Started out with just mac failing, but now linux is failing too. So far I am unable to reproduce any of the linux or mac failures locally.

Bumps actions/cache from 3.0.11 to 3.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps actions/checkout from 3.1.0 to 3.2.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Neither the hello_world nor the brotli example work "out of the box" e.g. they don't have a pubspec in their folder etc pp, which makes the barrier to enter WASM with dart quite high.

Also the "basic usage" example from the readme is not there as an "example" to investigate.

In order to run either example you have to first create a new project and copy the files over, which is not ideal.

Linking to https://github.com/flutter/flutter/issues/90218 since I tried to test WASM in isolation.

This PR contains a code generator that takes as input a minimal description of a WASM module, and outputs a String containing a valid Dart program that can be used to safely link to the imports and exports during the construction of a wasm module.

This PR only contains the generator part, a data source is still needed. In a follow up PR, a Wasmer based data source will be implemented.

This PR translates the example in the readme into a living example in the example directory. It also adds a C example that is essentially the same as the C++ example, but since they are considered different languages, I think it would be helpful to have separate examples for them.