This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: Proc goodness, enum badness
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
I should have a new release of proc/wait3 out soon. This originally started off as a port of the wait3 and wait4 methods, but I've been adding some of the other advanced process related methods. The next release will include:
I did hit one snag when wrapping sigsend, however. It seems Ruby's makemaker wrapper, mkmf, has no way of detecting an enum constant ahead of time. The values defined in signal.h for the idtype_t enum can vary from platform to platform, e.g. P_PROJID. This makes wrapping those constants in Ruby in a cross platform manner somewhat problematic. Basically, you'll have to check your idtype_t enum and hand-edit the source. Ick.
I plan on submitting a patch to ruby-core for a have_enum_member method very soon to deal with this. This is actually the first time it's ever come up for me when writing C extensions. It's unusual to see values like like that wrapped in an enum rather than defined with macro preprocessor constants, but the header file has a comment that indicates that its values conflict with some other library. I can only guess it has something to do with that.
Previous Topic
