From: Oliver <fwang2@...>
Date: 2007-07-17T10:35:44+09:00
Subject: Re: C library extension question

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.

thanks

Oliver



On Jul 16, 8:00 pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
> On Jul 16, 2007, at 16:50 , Oliver wrote:
>
> > Thanks for the suggestion, I will take a look at the sample lib you
> > suggested.
> > However, I don't fully understand the reasoning of "not wrapping it".
>
> I was just suggesting that thinking laterally might be an
> alternative. Obviously not if you're using a specific 3rd party
> library that you need to use. But if you just want an event engine,
> we're talking a TEENY amount of code in ruby (sans-leaks, sans-cores,
> sans-icky) compared to C.
>
> > Here is my line of thinking:
>
> > - the original C function register() expects an array of function
> > pointers, and those functions are suppose to be user-supplied and
> > implemented by C.
>
> what users at what level/language?
>
> > - Ideally, we should now allow those functions to be implemented by
> > ruby ... is this possible at all?
>
> I think you'd have to do some extra work to wrap up rb_funcall itself.