[#4076] Ruby/DL — Jamis Buck <jamis_buck@...>

I recently used Ruby/DL to create bindings to the SQLite3 embedded

40 messages 2005/01/03
[#4096] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/04

On Tue, Jan 04, 2005 at 02:53:49AM +0900, Jamis Buck wrote:

[#4099] Re: Ruby/DL — ts <decoux@...> 2005/01/04

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4119] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:

[#4120] Re: Ruby/DL — ts <decoux@...> 2005/01/05

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4125] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Thu, Jan 06, 2005 at 01:10:34AM +0900, ts wrote:

[#4116] Test::Unit::Collector::Dir won't work with code that modifies $LOAD_PATH — Eric Hodel <drbrain@...7.net>

Any test code that depends upon modifications of $: fails when used

10 messages 2005/01/05

[#4146] The face of Unicode support in the future — Charles O Nutter <headius@...>

Hello Rubyists!

47 messages 2005/01/06
[#4152] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/07

Hi,

[#4167] Re: The face of Unicode support in the future — Christian Neukirchen <chneukirchen@...> 2005/01/09

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#4175] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/10

Hi,

[#4186] Re: The face of Unicode support in the future — Paul Brannan <pbrannan@...> 2005/01/11

On Mon, Jan 10, 2005 at 11:53:48PM +0900, Yukihiro Matsumoto wrote:

[#4192] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/12

Hi,

[#4269] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...>

19 messages 2005/01/18
[#4270] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/18

Hi,

[#4275] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...> 2005/01/19

[#4323] test/unit doesn't rescue a Exception — Tanaka Akira <akr@...17n.org>

test/unit doesn't rescue a Exception in a test method, as follows.

14 messages 2005/01/27
[#8773] Re: test/unit doesn't rescue a Exception — Tanaka Akira <akr@...> 2006/09/02

In article <87is5jb46q.fsf@serein.a02.aist.go.jp>,

[#8776] Re: test/unit doesn't rescue a Exception — "Nathaniel Talbott" <ntalbott@...> 2006/09/03

On 9/1/06, Tanaka Akira <akr@fsij.org> wrote:

[#8777] Re: test/unit doesn't rescue a Exception — Eric Hodel <drbrain@...7.net> 2006/09/03

On Sep 2, 2006, at 6:34 PM, Nathaniel Talbott wrote:

Re: Ruby/DL

From: ts <decoux@...>
Date: 2005-01-06 15:54:50 UTC
List: ruby-core #4144
>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

P> I do not understand you.  Or perhaps you do not understand me, or maybe
P> both.

 Well, from dl.c

 ------------------------------------------------------------

  entry = -1;
  for (i=0; i < MAX_CALLBACK; i++) {
    if (rb_hash_aref(DLFuncTable, rb_assoc_new(INT2NUM(rettype), INT2NUM(i))) == Qnil) {
      entry = i;
      break;
    }
  }
  if (entry < 0) {
    rb_raise(rb_eDLError, "too many callbacks are defined.");
  }

  rb_hash_aset(DLFuncTable,
               rb_assoc_new(INT2NUM(rettype),INT2NUM(entry)),
               rb_assoc_new(type,proc));
  sprintf(fname, "rb_dl_callback_func_%d_%d", rettype, entry);
  return rb_dlsym_new((void (*)())rb_dl_callback_table[rettype][entry],
                      fname, RSTRING(type)->ptr);
 ------------------------------------------------------------

 rb_dlsym_new() will return a data struct

 You see the limitation with MAX_CALLBACK

 Then it's used in callback.func

 ------------------------------------------------------------

  obj = rb_hash_aref(DLFuncTable, rb_assoc_new(INT2NUM(0),INT2NUM(0)));
  proto = rb_ary_entry(obj, 0);
  proc  = rb_ary_entry(obj, 1);
  Check_Type(proto, T_STRING);
  if( RSTRING(proto)->len >= 15 )
    rb_raise(rb_eArgError, "too many arguments");
  rb_dl_scan_callback_args(buff, RSTRING(proto)->ptr, &argc, argv);
  retval = rb_funcall2(proc, id_call, argc, argv);

 ------------------------------------------------------------

 The hash DLFuncTable is used to retrieve `bloc' and `proto'

 The name of the function give the key for DLFuncTable, because it's
 hardcoded at compile time.

P> That function pointer must be unique, else dl does not know which
P> ruby callback object to call.

 That function don't need to be unique, if `bloc' and `proto' are *not*
 stored in DLFunctable, and indexed by the name of the function (sort of). 

 Look at rb_dl_callback_func_0_0() and rb_dl_callback_func_0_1() they do
 *exactly* the same thing except for these lines

  obj = rb_hash_aref(DLFuncTable, rb_assoc_new(INT2NUM(0),INT2NUM(0)));

  obj = rb_hash_aref(DLFuncTable, rb_assoc_new(INT2NUM(0),INT2NUM(1)));

 The problem with dl is that it has stored [bloc, proto] in an *external*
 structure (DLFuncTable) and it use the name of the function to retrieve
 the data.


Guy Decoux








In This Thread