rb_f_lambda vs. rb_block_proc : what are the issues?

[Jeremy Henty]

Now that I'm maintaining Ruby/FLTK, I'm seeing lots of "rb_f_lambda()
is deprecated" warnings from the tests and samples. I want to
eliminate them so I'm trying to figure out if I can simply replace it
by rb_block_proc() everywhere. Therefore I'd like to know a few
things:

* Do rb_f_lambda() and rb_block_proc() do exactly the same thing?
They call proc_alloc() with slightly different parameters but I
can't work out if this makes any difference. (Not for nothing is
"eval.c" called "Ruby Hell"!)

* If I replace rb_f_lambda() by rb_block_proc() will the code break
when built under Ruby 1.6.x ?

* If I have to #ifdef a macro to support both 1.6.x and 1.8.x , what's
a clean way to do it? Does extconf.rb support this, or do I have to
roll my own?

I've been Googling and searching ruby-talk but haven't found any hints
beyond "rb_f_lambda() is deprecated in Ruby 1.8.x".

Thanks in advance for any help,

Jeremy Henty

 

[ts]

J> * If I replace rb_f_lambda() by rb_block_proc() will the code break
J> when built under Ruby 1.6.x ?

yes,

J> * If I have to #ifdef a macro to support both 1.6.x and 1.8.x , what's
J> a clean way to do it? Does extconf.rb support this, or do I have to
J> roll my own?

svg% /usr/bin/ruby -vrmkmf -e 'have_func("rb_block_proc")'
ruby 1.8.2 (2004-12-25) [i686-linux]
checking for rb_block_proc()... yes
svg%

svg% ./ruby -vrmkmf -e 'have_func("rb_block_proc")'
ruby 1.6.8 (2002-12-24) [i686-linux]
checking for rb_block_proc()... no
svg%




Guy Decoux

 

[Jeremy Henty]

J> * If I have to #ifdef a macro to support both 1.6.x and 1.8.x , what's
J> a clean way to do it?

svg% /usr/bin/ruby -vrmkmf -e 'have_func("rb_block_proc")'

OK, so if I add 'have_func("rb_block_proc")' to extconf.rb and:

#ifndef HAVE_RB_BLOCK_PROC
#define rb_block_proc rb_f_lambda
#endif

to the header file, I can globally replace rb_f_lambda by
rb_block_proc everywhere else and the result will build under 1.6.x ?

I don't have time to test this before I go to work but I will this
evening (unless someone points out some pitfall I've missed).

Sorry for the newbie questions but since I'm managing a public project
now I really want to do this the best way.

Thanks for your help,

Jeremy Henty

 

[Tim Hunter]

OK, so if I add 'have_func("rb_block_proc")' to extconf.rb and:

#ifndef HAVE_RB_BLOCK_PROC
#define rb_block_proc rb_f_lambda
#endif

to the header file, I can globally replace rb_f_lambda by
rb_block_proc everywhere else and the result will build under 1.6.x ?

I don't have time to test this before I go to work but I will this
evening (unless someone points out some pitfall I've missed).

For the sake of the people who will maintain this code after you've
moved on, I suggest you pick a 3rd, all-caps, symbol to use as the
preprocessor symbol:

#if defined(HAVE_RB_BLOCK_PROC)
#define BLOCK_PROC rb_block_proc
#else
#define BLOCK_PROC rb_f_lambda
#endif

Since it's very common to make preprocessor symbols all-caps (and very
uncommon for function names to be all-caps) when the next maintainer
starts looking at your source code, the BLOCK_PROC symbol will prompt
him/her to go look for its definition in a header file.

 

[Jeremy Henty]

... I suggest you pick a 3rd, all-caps, symbol to use as the
preprocessor symbol: ... Since it's very common to make preprocessor
symbols all-caps (and very uncommon for function names to be
all-caps) when the next maintainer starts looking at your source
code, the BLOCK_PROC symbol will prompt him/her to go look for its
definition in a header file.

I'm aware of that convention and I would *certainly* do that if I was
using macros to create a consistent API around inconsistent
lower-level APIs (in the same way that Glib/Gtk create a consistent
API on top of the Unix, Windows and Mac APIs). In these cases there
isn't any way to write portable code without creating such wrappers so
it's good to highlight their existence.

But this situation is different. Here I just want a workaround to
make pukka Ruby-1.8.x code build and run correctly on Ruby-1.6.x too.
It's a backward step to force a Ruby-1.8.x developer to use a new API
to write portable code when I can arrange for the build to silently do
the Right Thing on Ruby-1.6.x *even* if the developer knows nothing of
the portability issues. So in this case I prefer my approach. But
I'm willing to be persuded otherwise.

Cheers,

Jeremy Henty

 

[Jeremy Henty]

... I'm willing to be persuded otherwise.

Persuded? Where on Earth did I get *that* word from? Hmm, I guess it
could be an amalgam of "persuaded" and "deluded". I wonder if that
means anything?

Jeremy Henty