On Jul 16, 2007, at 18:35 , Oliver wrote:

> probably I didn't make myself clear:
>
> Under normal usage, the library expects user to supply some functions
> in C, such as func_a(), func_b(), through function pointers defined in
> above dispatch command structure.
>
> Now, from a wrapper stand point of view, I was hoping that the user-
> provided function func_a(), func_b() etc. can be done by ruby as well
> - it will be very awkward for a user to use partial c, partial ruby
> for the same library. I don't see why rb_funcall() can help in this
> case - in a sense, this case calls for a way to map ruby function into
> C function, for the sake of using the C library call.

I suggested rb_funcall because it is the C entry point into a ruby  
method. Since the function pointer signature doesn't match up with  
ruby's, I don't think you can share between C and ruby 1:1. But, you  
might be able to wrap it up in such a way that you can call through  
from C into ruby.

I wasn't suggesting the user work in a mix of the two, just you.

Really NonFunctional Basic Visual:

def func_a
   puts "yay!"
end

Workhorse.register :func_a

----

void rb_func_wrapper() {
   rb_funcall(rb_cKernel, ID2SYM(...));
}

void rb_register(VALUE sym_name) {
   register(rb_func_wrapper << N & SYM2ID(sym_name)); // or something  
equally scary
}

----

not that I think you can do that... but it is a thought.

----

Another thought, assuming you have the latitude, is to dynamically  
generate the C functions for register using something like RubyInline.