Node-motoko Question - Dependency on oCAML?

Developers Language Support
1

Hey @rvanasa, does GitHub - dfinity/node-motoko: Compile and run Motoko smart contracts in Node.js or the browser. still depend on the oCAML compiler in some way, or is it pure js?

Meta question for you + @lastmjs Could Azel compile/run a motoko contract with this?

1 Like
2

Looking through the code,y buest guess is the Motoko compiler has been compiled into Wasm, and can thus be used in node. Look at the versions/latest directory.

Azle could incorporate this at compile-time at least, Iā€™m not sure the use case though.

3

It looks to me like itā€™s been compiled to JavaScript and not Wasm: node-motoko/versions/latest at c906f862dad4d314aa60576134917cffe1908212 Ā· dfinity/node-motoko Ā· GitHub

The ability to do this type of thing has been around since:

3 Likes
4

If thatā€™s a goal for Azle maybe GitHub - dfinity/motoko.rs: Motoko concrete syntax parser in Rust. / GitHub - dfinity/ic-mo-vm is a better route.

Perhaps @matthewhammer or @rvanasa can comment on that.

5

The use case would be that a black-holed canister could compile open-source code in a dependable way, making sure that only ā€˜blessedā€™ versions of canisters can be deployed. There are other ways of doing this of course, and Cover is trying to serve some of these use cases, but as we move toward DAOs and autonomous software, it would be cool if these DAOs could automate deployment, upgrades, or even create composable canisters on the fly. Imagine a DAO builder that lets you pick modules from a list and then compiles and deploys the DAO for you.

3 Likes
6

For what itā€™s worth, Motoko Playground uses the JS version of the Motoko compiler as well.

Would that be a sufficient basis for what youā€™re describing?

7

Yep! node-motoko uses js_of_ocaml under the hood, so everything is pure JavaScript.

@matthewhammer and I are currently working on a Rust interpreter for Motoko, which we are calling ā€œMoVM.ā€ This is much closer to the metal compared to node-motoko (probably at least 2-3 orders of magnitude faster than js_of_ocaml running on Azle).

Here are some benchmarks for the project and an example canister for reference.

This project is very early in development, so it could still be worth looking into running the node-motoko compiler from an Azle canister. Here is the js_of_ocaml file (moc.js) which should contain everything you need if you want to try this experiment.

Cheers!

8

So the JS version of the Motoko compiler compiles Motoko to Wasm?

If so @skilesare this sounds possible to me. And hopefully it wouldnā€™t even need to be incorporated into Azle, you should be able to install it with npm. We just need to make sure that itā€™s self-contained i.e. doesnā€™t rely on any APIs not available to a canister.

2 Likes
9

moc.js uses a virtual file system, so itā€™s fully self-contained, at least up to browser compatibility.

Hereā€™s a code snippet for compiling IC Wasm from Motoko:

import { Motoko } from "./moc.min.js";

const source = 'actor { public query func example() : async Text { "Hello" } }';

Motoko.saveFile('Main.mo', source);
const result = Motoko.compileWasm('ic', 'Main.mo');

console.log(result.code.wasm); // Uint8Array(...)

I think thereā€™s a solid chance that this could work!

2 Likes
10

Very cool, I will have to try this out to see if it works

11

Is the compiler completely synchronous? Azle doesnā€™t have support for promises or async/await yet.

12

Just confirmed that moc.js is fully synchronous.

1 Like
13

Very nice, Iā€™m excited to test this out

4 Likes
14

This doesnā€™t currently work in Azle for a couple reasons, one being this syntax error problem: node-motoko causes syntax error Ā· Issue #749 Ā· demergent-labs/azle Ā· GitHub That might be a bug with the underlying Boa JS engine.

Another problem has to do with the next version of Azle, we have some buffer size issues with the way were handling some things, and because the node-motoko code is so large (~2mb) this causes problems.

15

Just checked back on this thread. The syntax error does seem like a bug with the Boa engine. It might be more feasible to run the interpreter (using motoko/versions/latest/moc_interpreter.min.js), although this would still be about 1.2 MB of generated code.

This was certainly worth a try! Iā€™ll keep this in the back of my mind in case thereā€™s a way to eventually make this work.

1 Like
16

Once the Wasm binary limit is increased the 1.2mb should be a non-issue Iā€™m hoping. The syntax error is interesting and I will look into it more later, maybe once the Wasm binary limit is lifted.

1 Like