[AssemblyScript] porting source from JS to AS

[StEvUgnIn]

Follows #420

[StEvUgnIn]

Final steps are:

• [x] Fix typings between JS and AS/TS
• [x] Be able to work fully with emitted JS from AS implementation
• [ ] Write an encapsulated interface layer for using WASM from any web programming environment
• [ ] Port Mocha to AS/TS spec (as-pect)
• [ ] Benchmark performances between JS and AS modes

Please comment here if you are interested to generously help. ⚡✨🚀

-- Documentation https://mochajs.org/ https://tenner-joshua.gitbook.io/as-pect/

[trusktr]

This will be neat for AS users to have!

Is there a particular reason to commit the build artefacts to the repo? Those can be built during publish time when publishing to NPM for example.

Why build Wasm modules?

If people will import the JS code into their JS projects, or import the AS code into their AS projects, then the module builds would not be needed. The Wasm modules are needed only for JS users who would import the Wasm modules instead of the JS code.

Wondering if that's it's worth building modules. Would the barrier between JS and Wasm allow this to be faster?

It would be sweet to see what perf diff looks like in a JS example that makes many calls into the module, vs plain JS and vs plain AS.

[StEvUgnIn]

Hi @trusktr

This will be neat for AS users to have!

Thanks! I hope we could see more WebGL frameworks emerge on the WebAssembly platform and this helps to train programming in Assemblyscript 🙂

Is there a particular reason to commit the build artefacts to the repo? Those can be built during publish time when publishing to NPM for example.

I was unsure at first, but I decided to include this because of the AssemblyScript conventions and I suppose someone could just download the file to include it in an existing project, especially during this testing phase.

Why build Wasm modules?

If people will import the JS code into their JS projects, or import the AS code into their AS projects, then the module builds would not be needed. The Wasm modules are needed only for JS users who would import the Wasm modules instead of the JS code.

Yes, exactly.

A default .gitignore lies in the build repository which actually lets you keep the built modules by default.

Wondering if that's it's worth building modules. Would the barrier between JS and Wasm allow this to be faster?

It would be sweet to see what perf diff looks like in a JS example that makes many calls into the module, vs plain JS and vs plain AS.

I am looking forward to try both implementations from the browser 😃

[StEvUgnIn]

I have a weird compiler output due to type declared inside modules yet.. https://gist.github.com/StEvUgnIn/acbfed089a24b1c671f79b1a36723a06

But so far, it seems to go well.

Edit: I have modified the utility bundle-dts.ts, so it now looks for these type problems until I find how to declare types else where using typescript

diff --git a/utils/bundle-dts.js b/utils/bundle-dts.js
index c7bcd55..82be43a 100644
--- a/utils/bundle-dts.js
+++ b/utils/bundle-dts.js
@@ -2,7 +2,7 @@ const fs = require("fs");
 const path = require("path");

 let sourcePath = "./dist/index.d.ts";
-let sourceTypingsPath = "./src/types.d.ts";
+let sourceTypingsPath = "./assembly/index.d.ts";
 let sourceTypings = fs.readFileSync(sourceTypingsPath, "utf-8");
 let typings = fs.readFileSync(sourcePath, "utf-8");
 let typingsLength = typings.length;
@@ -37,4 +37,12 @@ typings = "\n" + sourceTypings.replace(/declare/g, "export") + "\n" + typings;
 // Wrap them in a "gl-matrix module"
 typings = 'declare module "gl-matrix" {\n' + typings + "\n}";

+// Place assemblyscript reference path to the top
+typings = typings.replace(/\n\n\/\/\/ <reference path=\"[^\"]+?\" \/>/g, "");
+
+typings = `
+/// <reference path="../node_modules/assemblyscript/std/portable/index.d.ts" />\n
+${typings}
+`;
+
 fs.writeFileSync(sourcePath, typings, "utf-8");

[StEvUgnIn]

JavaScript output now renders

[mrchantey]

32 Bit Support

This PR is great! I'm in the process of implementing the brach in my project now. I'd just like to flag the 64 bit operations. We may want to have flexibility, for either allowing users to make the call at runtime, or exporting two seperate builds. For starters we could declare something like the following in common.ts and then use it throughout the library (I have no idea if this actually compiles)

//64 
export type Float = f64
export type FloatArray = Float64Array
export const FloatMath = Math

//32
export type Float = f32
export type FloatArray = Float32Array
export const FloatMath = Mathf

[StEvUgnIn]

Hello @mrchantey,

Please you are welcome for trying and sharing your proposition.

[StEvUgnIn]

I didn't make any advancement on this PR. I was waiting for as-bind to support Array/Float32Array/Float64Array before going any further.