2010/11/30 Dag Sverre Seljebotn <[email protected]>:
> On 11/30/2010 08:26 PM, Robert Bradshaw wrote:
>> On Tue, Nov 30, 2010 at 10:52 AM, Dag Sverre Seljebotn
>> <[email protected]> wrote:
>>
>>> On 11/30/2010 07:28 PM, Robert Bradshaw wrote:
>>>
>>>> On Tue, Nov 30, 2010 at 2:12 AM, Dag Sverre Seljebotn
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>>> On 11/30/2010 06:35 AM, Robert Bradshaw wrote:
>>>>>
>>>>>
>>>>>> On Mon, Nov 29, 2010 at 9:20 PM, Vitja Makarov<[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 2010/11/30 Robert Bradshaw<[email protected]>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mon, Nov 29, 2010 at 12:27 PM, Greg Ewing
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Stefan Behnel wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> * it makes the inner C function directly callable, thus making it
>>>>>>>>>> easier to
>>>>>>>>>> implement things like cpdef functions and generators on top.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> If you mention the name of such a function without calling it,
>>>>>>>>> does it refer to the C function or the Python function?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That would depend on the context in which it's being used.
>>>>>>>> Essentially, the as_variable attribute would be set, allowing it to
>>>>>>>> coerce to a Python object if need be.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I see problem with closures here where should scope object be created
>>>>>>> in C function or in wrapper?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> The only handle you can get of a closure object is a Python one.
>>>>>> (Well, eventually we want to have cdef closures, but we're not there
>>>>>> yet, and wouldn't be compatible with cdef functions--we'd probably
>>>>>> expose them as structs with a state and function pointer attributes.)
>>>>>>
>>>>>>
>>>>>>
>>>>> Just for reference: Carl recently made me aware that ctypes contain some
>>>>> code to proxy Python functions to C function pointers. And apparently it
>>>>> contains a small compiler that creates new CPU code on demand for this.
>>>>> I'm not sure how well that would be exposed for our purposes, if it has
>>>>> a C API or not. (I haven't really looked at this myself.)
>>>>>
>>>>> Being able to create a closure in Cython and pass it as an ordinary C
>>>>> function callback, without having to manage the context manually, would
>>>>> be a really cool feature! And with such a mini-compiler it is possible.
>>>>>
>>>>> (Same idea applies to a concept of "pointer to bound cdef method")
>>>>>
>>>>>
>>>> Wow, that's a pretty interesting idea. Does this limit the
>>>> applicability to certain architectures? Of course even if the context
>>>> needs to be handled separately, we could make it easier than it is
>>>> now.
>>>>
>>>>
>>> Spending five more minutes on this, ctypes uses the libffi library
>>> (which is simply bundled with Python, although I haven't probed into
>>> whether this means it will always be available in a form we can link
>>> with). It appears to be very user-friendly, and has specific routines
>>> for creating C closures.
>>>
>>> Google it to see platform availability. Apparently closures are not
>>> available on every platform, but a grep through the source for
>>> FFI_CLOSURES seem to indicated that the "moxie", "m32r" and "m68k"
>>> platforms are the only ones without closure support. I can live with
>>> that :-) Looks to me like libffi lies at the core of a lot of FFI out
>>> there so that support is rather good.
>>>
>> Very cool. I'm completely fine with relying on this library (bundled
>> with Python) for our use. The only downside is that documentation
>> seems a bit sparse, but I'm sure we can figure it out.
>>
>
> There's an "info" file in the doc subdir in the tarball, not sure if you
> saw that. It has some examples of use at least.
>
> Dag Sverre
>
>
>>
>>> At any rate, it seems tempting to just make Cython cdef closures simply
>>> be libffi closures.
>>>
>> Yep. This would give a nice way to get bound cdef methods as well
>> (though I could see value in being able to go back to the unbound
>> version, not sure how easy that would be).
>>
>> - Robert
>> _______________________________________________
>> Cython-dev mailing list
>> [email protected]
>> http://codespeak.net/mailman/listinfo/cython-dev
>>
I don't like the idea to add one more external dependency. But if that
really helps its okay.
Also libffi is not supported on blackfin architecture :(
Here is simple example from libffi documentation:
#include <stdio.h>
#include <ffi.h>
/* Acts like puts with the file given at time of enclosure. */
void puts_binding(ffi_cif *cif, unsigned int *ret, void* args[],
FILE *stream)
{
*ret = fputs(*(char **)args[0], stream);
}
int main()
{
ffi_cif cif;
ffi_type *args[1];
ffi_closure *closure;
int (*bound_puts)(char *);
int rc;
/* Allocate closure and bound_puts */
closure = ffi_closure_alloc(sizeof(ffi_closure), &bound_puts);
if (closure)
{
/* Initialize the argument info vectors */
args[0] = &ffi_type_pointer;
/* Initialize the cif */
if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1,
&ffi_type_uint, args) == FFI_OK)
{
/* Initialize the closure, setting stream to stdout */
if (ffi_prep_closure_loc(closure, &cif, puts_binding,
stdout, bound_puts) == FFI_OK)
{
rc = bound_puts("Hello World!");
/* rc now holds the result of the call to fputs */
}
}
}
/* Deallocate both closure, and bound_puts */
ffi_closure_free(closure);
return 0;
}
I don't actually understand how do you want to use libffi in Cython.
Can you provide some usecase, please?
vitja.
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
