I have been discussing improvements to "libcall" with Bram, and I
would like to get feedback from you.
My specific issue is I want to interface with SQLite directly. I
wrote some new functions in my personal version of vim, but they are
not general enough to satisfy Bram, and he's right in this case :)
Basically, this is what is desired:
1. The ability to demand-load an arbitrary function from an arbitrary
DLL/SO, and deal with the parameters in an easy way.
2. The ability to write a 'callback' function in vimscript, also
dealing with parameters etc. in a reasonable way.
The 'callback' functionality is necessary for interfacing with lots of
DLLs - SQLite, expat and many others. Of course it is possible to
write a wrapper dll and use the existing 'libcall' interface -- and in
fact, I was doing that for years -- but the existing libcall loads and
unloads the DLL every time it's called, making stateful usage very
difficult.
I propose a demand-loading mechanism like:
call libfunc('dll_function', 'dll_name', "isi",
'VimNameForFunction')
(anyone have a better syntax in mind?)
So when 'VimNameForFunction' is called, it expects three paramters
(isi) to be passed to it, an integer a string and another integer. It
will then call the 'dll_function' in 'dll_name' (loading dll_name if
it is not already loaded). I use something similar in my Reva Forth.
This way, the dll is not loaded unless it is needed, and the binding
takes place dynamically. When vim quits, the libraries loaded would
be unloaded.
Parameter conversion should be done behind the scenes, and vim can
warn of improper parameter types or missing parameters.
Likewise, a 'callback' might be declared like:
callback MyCallback ( "ssi" )
let a = callback_param(0)
...
endcallback
I think the syntax is reasonable - what do you think?
Bigger question in my mind is how to implement callbacks in vim-
script. In Reva it's not a huge problem, as it generates native
code. But vimscript is completely interpreted, so I am guessing we
need to have a way to have a "thunk" which is passed to the C code in
the DLL, but which when called knows where to vector to.
It may be reasonable to have a limited number of callbacks available,
though that would be an unfortunate restriction. Any ideas on this?
Oh, one last thing. in the callback example mentioned above, typing
"MyCallback" should provide the address of the callback to be passed
to calling code. Vim code should never call a 'callback' directly, of
course.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---