using void* in LuaJIT2 FFI

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

using void* in LuaJIT2 FFI

Stefan Behnel
Hi,

I'm thinking about using LuaJIT's FFI in the next lupa release to provide
access to CPython's buffer interface. This would allow direct low-level
access to NumPy matrices and the like, thus providing an efficient Lua
companion for the huge set of scientific computation libraries in SciPy,
Sage and the like.

Now, these buffers are basically represented as a struct containing a void*
together with layout meta data, and it's up to the code that uses them to
cast the pointer to the appropriate item type. This cannot be handled
transparently inside of lupa, as only the user code will know the correct
type to use. So I'm wondering how to best design the interface here. From
the current documentation at

http://luajit.org/ext_ffi.html

which is more tutorial style than a reference, I cannot see how such a
runtime cast would be supported.

Is there a way to cast a void pointer in LuaJIT-FFI code?

OTOH, I could also imagine letting the user code provide the item type as a
string so that lupa could generate corresponding FFI definition (C) code on
the fly that simply defines the returned buffer struct with a pointer of
the provided type (instead of using the original C declaration).

Any comments here?

I'm also missing an example of how to actually inject C pointers into the
FFI using code. Does the FFI automatically dereference (light)userdata
objects, for example?

Stefan


Reply | Threaded
Open this post in threaded view
|

Re: using void* in LuaJIT2 FFI

Mike Pall-24
Stefan Behnel wrote:
> From the current documentation at
>
> http://luajit.org/ext_ffi.html
>
> which is more tutorial style than a reference, I cannot see how such
> a runtime cast would be supported.

Quoting, emphasis mine:

  "This page gives a short introduction to the usage of the FFI
  library. PLEASE USE THE FFI SUB-TOPICS IN THE NAVIGATION BAR TO
  LEARN MORE."

Please tell me what's unclear about this sentence.

> Is there a way to cast a void pointer in LuaJIT-FFI code?

I was under the impression that ffi.cast might be an intuitive
name for such a function, but you proved me wrong:

  http://luajit.org/ext_ffi_api.html#ffi_cast

> OTOH, I could also imagine letting the user code provide the item
> type as a string so that lupa could generate corresponding FFI
> definition (C) code on the fly that simply defines the returned
> buffer struct with a pointer of the provided type (instead of using
> the original C declaration).
>
> Any comments here?

The first item in the glossary of
  http://luajit.org/ext_ffi_api.html
is pretty clear about that:

  "... C type declaration (a Lua string)"

The whole point is to construct C types at runtime. In fact,
that's the only way to do it.

> I'm also missing an example of how to actually inject C pointers
> into the FFI using code.

Usually you'd get it as a return value from a C call.

> Does the FFI automatically dereference (light)userdata objects,
> for example?

http://luajit.org/ext_ffi_semantics.html#convert_fromlua

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: using void* in LuaJIT2 FFI

Stefan Behnel
Mike Pall, 12.02.2011 17:25:

> Stefan Behnel wrote:
>>  From the current documentation at
>>
>> http://luajit.org/ext_ffi.html
>>
>> which is more tutorial style than a reference, I cannot see how such
>> a runtime cast would be supported.
>
> Quoting, emphasis mine:
>
>    "This page gives a short introduction to the usage of the FFI
>    library. PLEASE USE THE FFI SUB-TOPICS IN THE NAVIGATION BAR TO
>    LEARN MORE."
>
> Please tell me what's unclear about this sentence.

Well, the content of that sentence isn't the problem. Its placement is.

Maybe it would help if the "sub-topics" actually *were* sub-topics, i.e. if
there was a topic "FFI", instead of several more or less unrelated topics
at the same level.

But I must admit that I didn't even look at the menu. A page titled "FFI
library" without any links in the text feels like a stand-alone page, not
so much as an intro to a larger part of a web site. You may want to add
some visible links to the relevant pages, rather than hiding a textual
reference in a tiny paragraph that's easy to miss. That's not how the web
works.

I'll give it a look. Thanks a lot for the pointers so far.

Stefan