daxpedda
daxpedda
I believe `wasm-pack` fulfills two purposes for us: 1. Configuration-free usage with `cargo`. E.g.`cargo run`, `cargo test` and such. 2. Integration with the JS ecosystem, e.g. `webpack` (I know next...
Yeah the idea is that it would be maintained by us. Personally I'm not keen to maintain `wasm-pack` as the last time I looked at it, it seems to have...
I think its still worth to explore a `cargo-*` binary to make it truly configuration-free. Apart from the whole JS ecosystem integration `wasm-pack` provides, that we probably don't want to...
> I'm not sure what you're referring to there tbh. I don't think it does anything special to JS+Wasm aside from building with Cargo and running wasm-bindgen. I'm talking about...
> > But just the regular output of `wasm-pack build` includes more `.js` files, a `package.json` and more `wasm-bbindgen` doesn't do. > > `package.json` yes, but there shouldn't be any...
Adjusted the naming conventions to the suggestion applied in #789.
Indeed. As I was saying in the OP: this is currently only used in hash2curve. This PR just improves existing code, I didn't add this function. But #1306 properly exposes...
> > we don't allow invalid y-coordinates (we reduce the input) > > That doesn't mean a prospective y-coordinate will be a valid solution to the curve equation. I see,...
I went ahead and removed the check for torsion-freeness as well, following the RFC.
AFAIK this should indeed not require any changes in `web-sys`, as this part of the code should never be executed unless demanded. If it turns out that somehow just the...