Re: typed arrays

[Coda Highland <chighland@...>]

On Sun, Sep 30, 2012 at 4:50 PM, Tom <tmbdev@gmail.com> wrote:
>> > Well, let's say I have an ImageMagic library and an ndarray library.
>> > How do
>> > I use your memoryview module to convert the ImageMagic image to an
>> > ndarray?
>> >
>> > -- load an image using ImageMagick library
>> > img = Image()
>> > img:open("lena.jpg")
>> >
>> > -- allocate an array
>> > a = ndarray(img.height,img.width)
>> >
>> > -- efficiently copy the pixels of img into a
>> >>>> put some FFI expression here <<<
>>
>> Using LuaJIT or luaffi, it's probably going to be something along the
>> lines of:
>>
>> ffi.C.memcpy(img.data, a.pointer, img.bytes)
>>
>> but I don't know the APIs of either of those objects you're describing.
>
>
> OK, so let's say I am a library writer and want people to be able to do
> that.  What data types should img.data and a.pointer be?  You're basically
> declaring ffi to be the standard for 1D typed arrays, and it's a standard
> that is very complex and totally unsafe.  Putting simple 1D typed arrays
> into the core would provide a simple type that img.data and a.pointer could
> return, plus the ability to write safe native code for copying the data
> around.
>
> Anyway, the discussion has made it clear that there is no current effort and
> no significant interest in adding such a type to Lua.  Thanks to everybody
> for the feedback.
>
> Tom
>

Could be a string or could be a lightuserdata or could be a userdata
or could be a cdata (in LuaJIT; luaffi doesn't have cdata types).
LuaJIT and luaffi will transparently convert strings to char* (which
means it'd probably be ffi.C.memcpy(img.data, a.pointer, #img.data)
instead) and the other three are already pointers on the C side.

Such a function wouldn't be added to the Lua language itself. It
doesn't fit into the concept of Lua being a no-frills,
batteries-not-included, minimalist, embeddable language. It would be
provided as a library, and then that library would need to gain enough
popularity in the community to become a de-facto standard. And if
you're talking about de-facto standards in terms of popular libraries,
the LuaJIT API is currently the most popular choice, because if you're
in an application that has that high of performance needs you're
probably using LuaJIT anyway, and if you're interfacing with unrelated
C libraries you're probably dealing in C data structures already.

Now, I speak as a user; I don't have any more voice in the matter than
anyone else, but this does appear to be the way things are currently
moving.

/s/ Adam