dbuenzli
Compatibility with Wasm_of_ocaml
Wasm_of_ocaml uses a different representation for OCaml floats (and 32-bit integers) and JavaScript numbers, so we need explicit conversions (which are still optimized away by Js_of_ocaml).
Also, since JavaScript values get boxed, physical equality can no longer be used to test whether a value is undefined.
This relies on additional runtime primitives introduced in https://github.com/ocsigen/js_of_ocaml/pull/1492.
The changes are rather simple and backward compatible, except for typed arrays.
Thanks!
I'm not sure I got the change on typed array. Does it mean we now need to use Jv.t values to access most of the types (e.g. on a Tarray.fill). That feels a bit wrong why do we loose the OCaml types (The former 'a parameter now shifted to 'b) ?
Also just noting for myself that this bit of doc regarding equalities will need updating.
I'm not very happy with the change on typed array, but I'm not sure how to do any better.
OCaml numbers and JavaScript numbers do not coincide, except for 31-bit integers. Tarray.fill takes a JavaScript number as argument, so in most cases, the best type we have for this argument is Jv.t.
Right but I mean we do have the types in Bigarray which are implemented via typed arrays. So I don't understand why we can't have them in Brr.Tarray like before.
One could dispatch on the constructor's name to perform the appropriate conversion. But this is going to add a lot of overhead to Tarray.get and Tarray.set. But maybe we can add specialized variants?
But maybe we can add specialized variants?
That could be an option, or maybe simply deprecate these function and ask people to convert to bigarrays for operations involving elements. Presumably this will then use bigarray primitives which have no overhead ? And we can then avoid adding this new parameter to Tarray.t ?
The bigarray primitives have less overhead, indeed. They make a dispatch based on the kind of the bigarray (which is an integer), rather that on the name of the typed array constructor.
So, I have inserted appropriate conversions instead of changing the types.
@vouillon what's the status of this ? I might do a release in the upcoming weeks.
@dbuenzli You need to review the changes regarding typed arrays. It should be ready to merge otherwise.