[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

rb_f_lambda vs. rb_block_proc : what are the issues?

Jeremy Henty

5/30/2005 8:56:00 PM

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
5 Answers

ts

5/31/2005 6:08:00 AM

0

>>>>> "J" == Jeremy Henty <jeremy@chaos.org.uk> writes:

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

6/1/2005 7:50:00 AM

0

In article <200505310607.j4V67vTW003371@moulon.inra.fr>, ts wrote:
>>>>>> "J" == Jeremy Henty <jeremy@chaos.org.uk> writes:
>
>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

6/1/2005 12:23:00 PM

0

Jeremy Henty wrote:
> In article <200505310607.j4V67vTW003371@moulon.inra.fr>, ts wrote:
>
>>>>>>>"J" == Jeremy Henty <jeremy@chaos.org.uk> writes:
>>
>>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).
>

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

6/2/2005 9:50:00 PM

0

In article <d7k9b4$nqi$1@license1.unx.sas.com>, Tim Hunter wrote:

> Jeremy Henty wrote:
>> 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 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

6/3/2005 4:31:00 PM

0

In article <slrnd9uvb7.9lb.jeremy@ganglion.onepoint>, Jeremy Henty
(ie. me) wrote:
> ... 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