Update JS_NewTypedArray() to C level API

[xeioex]

No description provided.

[saghul]

For strings we have an api that copies data and one that doesn't. Should we have the same here? /cc @chqrlie

[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 ?

[saghul]

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.

[kasperisager]

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.

[chqrlie]

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.

[saghul]

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.

[kasperisager]

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

@chqrlie The js_typedarray_type_t enum is ABI compatible with napi_typedarray_type to make conversion a simple cast:

OK node has the enum, not v8... We should definitely renumber our own enum to make it compatible.

[kasperisager]

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

[xeioex]

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

[xeioex]

but the one I use the most is the one that doesn't copy.

Zero-copy version sounds good too.