jaq icon indicating copy to clipboard operation
jaq copied to clipboard

Added support for WASIX and published it to Wasmer!

Open syrusakbary opened this issue 1 year ago • 5 comments

First of all, congrats on the awesome work... love what you are doing!

I compiled the project to WASIX to allow running jaq anywhere via WebAssembly (even on the browser!). I also published under jaq/jaq in Wasmer (please let me know if you have a Wasmer username so I can add you to the namespace).

This PR is fairly simple, but it allows running jaq just with wasmer:

echo '{"a": 1, "b": 2}' | wasmer run jaq/jaq '.a'

I'm happy to add CI integration as well, so it's automatically published in the future. Just let me know!

syrusakbary avatar Nov 29 '23 18:11 syrusakbary

How can I use it in browser? I got an error like:

jaq.js:9 Uncaught (in promise) TypeError: fs.readFile is not a function

loggerhead avatar Dec 07 '23 09:12 loggerhead

Hi @syrusakbary, thanks for this interesting work!

I'm fine with most changes, but what is your motivation for your changes to Cargo.toml, in particular leaving out codegen-units and adding lto? Also, how about making the version number of the Wasmer release match the actual jaq version number?

01mf02 avatar Jan 09 '24 13:01 01mf02

How can I use it in browser?

Yes, thanks to the new released Wasmer SDK you can simply use the jaq/jaq package.

I'm fine with most changes, but what is your motivation for your changes to Cargo.toml, in particular leaving out codegen-units and adding lto?

The main reason is that otherwise the Wasm file generated was not runnable by the runtime (it was generating a wasm file with functions too big to be processed by the Wasm runtime).

Also, how about making the version number of the Wasmer release match the actual jaq version number?

That makes complete sense. I'll fix that!

Also, @01mf02 do you have an account in Wasmer so I can add you as admin to the package as well?

syrusakbary avatar Jan 09 '24 13:01 syrusakbary

The main reason is that otherwise the Wasm file generated was not runnable by the runtime (it was generating a wasm file with functions too big to be processed by the Wasm runtime).

I thought something like this. Is there a way to specify these flags so that they are only used for the WASM build? (Otherwise they might have negative performance implications on the regular builds.)

That makes complete sense. I'll fix that!

Great!

Also, @01mf02 do you have an account in Wasmer so I can add you as admin to the package as well?

I just created one. It's called 01mf02. :)

01mf02 avatar Jan 10 '24 11:01 01mf02

@syrusakbary, I might have found a partial way towards running WASM builds with different flags. On this article, I found the following syntax:

[profile.profiling]
inherits = "release"
debug = true

So we could make a profile "wasm" or something like that, let it inherit "release" and then set whatever other flags it needs.

01mf02 avatar Jan 12 '24 12:01 01mf02