Hi, this topic has already been discussed in 2008, and became dead.
Time to make it born again.
I was talking with Bram about the limitations of libcall: the load/unload
of a library at every invocation and the arguments limitations.
I talked about a small change on it to avoid the load/unload problem
which is to split the function in three: libload, libcall and libfree. He gave
the idea of checking whether the first parameter of libcall is a string or
not, if not, it's a handle returned by libload, so a call without the overhead
of load/unload is to be made.
1 - That's a small propose to turn things a little better.
Then, he proposed to extend the idea for an implementation where a
VIM list would be passed as function arguments to call a native function,
but pointed out the tricky part would be to make a call given a list of
unknown size.
I'd already known of approaches as that of libcallex but was a little
worried. So then, after some research, I found how python ctypes
and others do that by using libffi. It's just the libcallex approach, but
packed in a good interface and ported and tested in several
platforms and compilers.
FFI stands for Foreign Function Interface.
Here's an example of using libffi:
#include <stdio.h>
#include <math.h>
#include <ffi.h>
int main()
{
ffi_cif call_interface;
ffi_type *arg_types[2];
ffi_type *ret_type;
/* pow signature */
arg_types[0] = &ffi_type_double;
arg_types[1] = &ffi_type_double;
ret_type = &ffi_type_double;
/* prepare pow function call interface */
if (ffi_prep_cif(&call_interface, FFI_DEFAULT_ABI, 2, ret_type, arg_types)
== FFI_OK)
{
void *arg_values[2];
double x, y, z;
/* arg_values elements point to actual arguments */
arg_values[0] = &x;
arg_values[1] = &y;
x = 2;
y = 3;
z = 0;
/* call pow */
ffi_call(&call_interface, FFI_FN(pow), &z, arg_values);
/* 2^3=8 */
printf("%.0f^%.0f=%.0f\n", x, y, z);
x = 3;
y = 2;
z = 0;
/* call pow */
ffi_call(&call_interface, FFI_FN(pow), &z, arg_values);
/* 3^2=9 */
printf("%.0f^%.0f=%.0f\n", x, y, z);
}
return 0;
}
2 - So, the hard propose is to create a new feature, +ffi, that would compile
VIM
linked to libffi and allow for calling native functions "somehow".
How then would be an implementation of calling native functions?
It could be an extended libcall accepting a VIM list to pass it's elements as
arguments.
It could be an extension to VIM Script allowing it to declare prototypes for
native functions.
Conversion between VIM types and libffi types is necessary.
libffi is MIT licensed and is adopted in several projects.
In this embryonary stage (I know nothing about VIM internals),
any suggestions? criticisms?
Regards
---
Francisco Lopes
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
