-
Notifications
You must be signed in to change notification settings - Fork 114
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
Switch to rquickjs
#618
Switch to rquickjs
#618
Conversation
Migrated the `Console` and `Random` APIs; got to the `StreamIO` API.
This commit migrates the `console`, `stream_io`, `random` and `text_encoding` APIs to use rquickjs. One notable change in this commit is the introduction of the `Args` struct to tie the lifetime of `Ctx<'js>` and `Rest<Value<'js>>` arguments, given that explicit lifetime binding is not possible in Rust closures at the moment.
aa9a9a8
to
878ddd5
Compare
Not quite ready for review, but almost. I want to see what CI says. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you didn’t solicit a review and I didn’t really do a full review, but I wanted to take a look where you are at and left 2 comments :3
a918d3b
to
85abf57
Compare
Ok, so all tests are passing here. I'm working on migrating our json/msgpack ser/de and that should be the last step (aside from vetting the new dependencies) to get this in a review-ready state. |
…nder the javy crate
`cargo` doesn't seem to pickup the fact that `quickcheck` is only used in tests.
And prune unused ones
I wanted to avoid as much as possible using the underlying QuickJS unsafe APIs, but that introduced behavioral changes and bugs. So for now, I'm sticking to the previous implementation.
5fde19c
to
29361f3
Compare
This commit introduces rquickjs 0.6.0 through a fork that contains Wasm specific performance improvements. We intend to upstream these improvements.
Adds special policy for rquickjs given that we're currently in a fork.
This commit is a follow-up to bytecodealliance#618, to formally mark `quckjs-wasm-{sys, rs}` crates as deprecated. The rollout strategy is to: * Merge this PR * Publish the a new version of each of the crates, containing the last unreleased change in each and the deprecation notice.
This commit is a follow-up to #618, to formally mark `quckjs-wasm-{sys, rs}` crates as deprecated. The rollout strategy is to: * Merge this PR * Publish the a new version of each of the crates, containing the last unreleased change in each and the deprecation notice.
Thanks a lot for doing rquickjs switch work .Till when can I expect the new release on github roughly ? |
Mid June is my estimate: we're doing more extensive testing and working on other improvements before releasing the next version. |
This commit removes the following deprecated crates from the tree: * `quickjs-wasm-sys` * `quickjs-wasm-rs` * `javy-apis` These crates were marked as deprecated as part of the migration to rquickjs: bytecodealliance#618 and they have also been removed from our `cargo vet` configuration in bytecodealliance#715
* Remove deprecated crates from tree This commit removes the following deprecated crates from the tree: * `quickjs-wasm-sys` * `quickjs-wasm-rs` * `javy-apis` These crates were marked as deprecated as part of the migration to rquickjs: #618 and they have also been removed from our `cargo vet` configuration in #715 * Remove `javy-apis` from cargo vet config
I'm trying to figure out which version of QuickJS that the Javy's master branch is using. Is it 2024-01-13 or 2023-12-09? |
https://github.com/bellard/quickjs/blob/3b45d155c77bbdfe9177b1e03db830d2aff0b2a8/VERSION -- we currently rely on |
Thanks @saulecabrera! |
Description of the change
Historically, the Javy project has relied on its own QuickJS bindings in order to consume QuickJS' functionality. When the project started, there were very limited options for bindings that could work for our use-case and more importantly, bindings that would compile to
wasm32-wasi
. That said, bindings under this project are "good enough" for Javy, but they are probably not the most ergonomic for use-cases that require more complex interactions with QuickJS.The Rust <> QuickJS landscape has changed in the past few years, which means that it's probably a good time to reconsider our initial decisions.
This PR proposes migrating to
rquickjs
and dropping support forquickjs-wasm-rs
andquickjs-wasm-sys
. Therquickjs
bindings are more ergonomic and enable more natural interactions between Rust and QuickJS' API.With the adoption of
rquickjs
, we'd be able to address issues like: #605, #608, #617 and #611.This change is divided in a series of commits, but it's better reviewed as a whole, given that I didn't put enough thought to make each commit self-contained.
In general, this change doesn't introduce any functional changes, dropping support for
quickjs-wasm-rs
is the only breaking change introduced by this PR. The only exception is that I fixed a bug in our number deserialization process, in which the implementation was not respecting theMIN_SAFE_INTEGER..=MAX_SAFE_INTEGER
range.This change is already big as-is; I'm planning on creating follow-up PRs for:
docs
quickjs-wasm-rs
andquickjs-wasm-sys
with a deprecation notice.Checklist
javy-cli
andjavy-core
do not require updating CHANGELOG files.