Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for WASIX and published it to Wasmer! #132

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

syrusakbary
Copy link

@syrusakbary syrusakbary commented Nov 29, 2023

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!

@loggerhead
Copy link

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

@01mf02
Copy link
Owner

01mf02 commented Jan 9, 2024

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?

@syrusakbary
Copy link
Author

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?

@01mf02
Copy link
Owner

01mf02 commented Jan 10, 2024

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
Copy link
Owner

01mf02 commented Jan 12, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants