bellard
Update `JS_NewTypedArray()` to C level API
For strings we have an api that copies data and one that doesn't. Should we have the same here? /cc @chqrlie
For strings we have an api that copies data and one that doesn't. Should we have the same here? /cc @chqrlie
What string APIs are you referring to?
Regarding typed arrays, the APIs should either create a view on an existing ArrayBuffer / SharedArrayBuffer or create the full view of an ArrayBuffer implicitly created from raw data. I am not sure what is the best way to approach this.
What are the needs for integrating QuickJS into larger applications ?
Sorry I think I was thing about arraybuffer.
In txiki.js I have both use cases, but the one I use the most is the one that doesn't copy. This is what I use for sockets, stdio and so on.
My own use case is replacing the implementation of this function: https://github.com/holepunchto/libqjs/blob/eff318a3c97839b55880bc52cc92ee6528005811/src/qjs.c#L2846-L2891. The function behaves the same as the various typed array constructors in that it takes an arraybuffer, an offset, and a length and constructs a view over that.
My own use case is replacing the implementation of this function: https://github.com/holepunchto/libqjs/blob/eff318a3c97839b55880bc52cc92ee6528005811/src/qjs.c#L2846-L2891. The function behaves the same as the various typed array constructors in that it takes an arraybuffer, an offset, and a length and constructs a view over that.
@kasperisager in your case, you want to bypass the overhead of JS_GetGlobalObject(env->context); and the appropriate JS_GetPropertyStr(env->context, global, class) but you would still potentially need to map your js_typedarray_type_t enum to QuickJS's new JSTypedArrayEnum.
What is js_typedarray_type_t enum modelled after ? I could not find an equivalent in v8.
Reordering our own enum should not be a problem (yet).
2 separate APIs seem to be advisable.
This is the little wrapper I use: https://github.com/saghul/txiki.js/blob/4896636f13dd298468c9f6b3d46cbc0dcbab12b3/src/utils.c#L262 since JS_NewUint8Array does not copy the data but needs a freeing function.
When reading data from a socket with libuv I allocate some memory and then that memory becomes the uint8array.
@chqrlie The js_typedarray_type_t enum is ABI compatible with napi_typedarray_type to make conversion a simple cast: https://github.com/nodejs/node/blob/8e6a45b3e5763bb065e4aa6f31f20e5b7cb58760/src/js_native_api_types.h#L94-L106
@chqrlie The
js_typedarray_type_tenum is ABI compatible withnapi_typedarray_typeto make conversion a simple cast:
OK node has the enum, not v8... We should definitely renumber our own enum to make it compatible.
Yep, for V8 we have to fetch the corresponding constructor function, it doesn't have a type enum: https://github.com/holepunchto/libjs/blob/41ba260766291ca2477a1473c652d5a5494e3f7d/src/js.cc#L3974-L4001
@chqrlie
Regarding typed arrays, the APIs should either create a view on an existing ArrayBuffer / SharedArrayBuffer or create the full view of an ArrayBuffer implicitly created from raw data. I am not sure what is the best way to approach this.
I agree, that is why the initial API was argc, argv.
The function behaves the same as the various typed array constructors in that it takes an arraybuffer, an offset, and a length and constructs a view over that.
How create a view on an existing ArrayBuffer / SharedArrayBuffer C prototype should look like?
What about:
int JS_NewTypedArrayFromBuffer(JSContext *ctx, JSTypedArrayEnum type, JSValue arrayBuffer, size_t offset, size_t length)?
I am not sure about what is the best arrayBuffer type.
but the one I use the most is the one that doesn't copy.
Zero-copy version sounds good too.