Re: typed arrays

[Tom <tmbdev@...>]

Thanks, but I don't see how that helps with the use cases I raised.  FFI is great for having Lua code access complex C structures and arrays and it provides "typed arrays", but it doesn't set an interoperability standard. In fact, the very ability to define so many different, incompatible types means that it won't fulfill that function.   (And for all its generality, it still doesn't offer functionality like Python buffers or views.)

For library interoperability, we need a simple, single, universal standard that's in the language core, that every library implementer knows about, and that can be used to move large amounts of data efficiently between completely unrelated libraries, for example:

data,w,h = opencv_image:to_typed_array()

img = ImageMagick(data,{w,h})

That's why other scripting languages have well-defined, simple typed arrays in the core, and Python got buffers and views as well.

Since I just don't seem to be able to communicate what I mean, I probably will just have to write a small library and post it.

Tom

On Thu, Sep 27, 2012 at 8:34 PM, Coda Highland <chighland@gmail.com> wrote:

http://luajit.org/ext_ffi_api.html

https://github.com/jmckaskill/luaffi/blob/master/README.md

On the Lua side, once it's been declared, it acts just like a table,
with API functions for additional manipulation. On the C side, it's
just a pointer of the desired type, which can be handled however you
want.

/s/ Adam

On Thu, Sep 27, 2012 at 8:28 PM, Tom <tmbdev@gmail.com> wrote:
> I'm not sure which LuaJIT API you are referring to; do you have a URL?  Does
> that API require any support from LuaJIT?
>
> Tom
>
> On Thu, Sep 27, 2012 at 8:13 PM, Coda Highland <chighland@gmail.com> wrote:
>>
>> On Thu, Sep 27, 2012 at 7:53 PM, Tom <tmbdev@gmail.com> wrote:
>> > A simple API might have four functions (using Lua syntax to describe
>> > both
>> > Lua and C APIs):
>> >
>> > a = typed_vector(size,tcode) -- allocs 1D array of the given size and
>> > type
>> > a:size() -- returns the size of the 1D typed array
>> > a:type_code() -- returns the type of the 1D typed array
>> >
>> > a[index] -- needed only in Lua, for simple element access
>> > a:address_of() -- needed only in C, pointer access to elements
>> >
>> > Type codes would exist for common standard C types ("char", "uint",
>> > "float",
>> > ...), and common sized types ("uint8", "float32", "float64"), ...).
>> >
>> > Although such a simple API may mean that getting two libraries to talk
>> > to
>> > each other may involve extra copying, even with that, it's a lot faster
>> > and
>> > easier than having nothing at all. A more complex interface would be a
>> > Lua
>> > adaptation of a subset of the Python buffer and memory view APIs
>> > (http://docs.python.org/c-api/buffer.html); they allow data to be
>> > exposed
>> > without copying, but at the cost of higher complexity.
>> >
>> > Tom
>>
>> It seems to me that the best API would be the one that's native to
>> LuaJIT, as that would provide the best performance there and work with
>> no further adaptation. Imitating that (e.g. luaffi) would allow
>> non-LuaJIT projects to use the same API.
>>
>> /s/ Adam
>>
>