Re: typed arrays

[Tom <tmbdev@...>]

I'm sorry, but people seem have been missing the point of my question.  It is easy to implement a typed array for Lua; I have several such implementations myself (binding vector with luabind is one easy such implementation).

The problem is that everybody is doing it differently.  Libraries that use large typed arrays (e.g., 3D graphics, image processing, etc.) each have their own typed array data types and it is impossible to move data efficiently from one to another without writing yet another extension.

Therefore, I think it would be good if there were a STANDARD for typed arrays, something that every extension that uses typed arrays can use as the basis for its own typed arrays, or at least provide conversions to/from.  That's the reason Python and _javascript_ moved typed arrays into the core, and I think it would be good for Lua to consider doing this too. It doesn't need to have many (or even any) operations on it, but it does need a C API that is available and acceptable to all extension writers.

Tom

On Thu, Sep 27, 2012 at 10:07 AM, Coda Highland <chighland@gmail.com> wrote:

On Thu, Sep 27, 2012 at 9:58 AM, Daniel Aquino
<mr.danielaquino@gmail.com> wrote:
> You could also do this with the C api though.
>
>
>
> On Thu, Sep 27, 2012 at 12:40 PM, Coda Highland <chighland@gmail.com> wrote:
>> On Thu, Sep 27, 2012 at 9:29 AM, Tom <tmbdev@gmail.com> wrote:
>>> I was wondering whether there was any standard on typed arrays in the works,
>>> similar to what _javascript_ offers.
>>>
>>> Of course, there are several libraries that provide this functionality, but
>>> the main use of typed arrays that I have isn't so much for
>>> computing/scripting with them (they are nice for that to be sure), but for
>>> interoperability between libraries with different array types: if each
>>> library knows how to convert to/from a standard typed array,
>>> interoperability becomes much easier.
>>>
>>> The ideal library might go a bit beyond the JS facility and allow both owned
>>> storage and pointing to already allocated storage in an existing structure
>>> (the user of the library would have to make sure that that's safe), and
>>> would provide array descriptors allowing for non-standard strides.  But even
>>> a simple, standard 1D dense vector would greatly improve interoperability.
>>>
>>> T
>>
>> LuaJIT offers this through its FFI types. Perhaps you should check that out.
>>
>> /s/ Adam
>>
>

Indeed, you could write a few C functions to deal with a userdata or
lightuserdata object wrapping around a C or C++ vector.

/s/ Adam