This post originated from an RSS feed registered with Ruby Buzz by Ryan Davis. Original Post: RubyInline Myths Feed Title: Polishing Ruby Feed URL: http://blog.zenspider.com/index.rdf Feed Description: Musings on Ruby and the Ruby Community... Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Ryan Davis Latest Posts From Polishing Ruby

I just read the RubyInline section (22.4) of the Ruby Cookbook by Lucas Carlson and Leonard Richardson. I'm a bit ticked off so calibrate accordingly. In the discussion there are blatant errors. A lot of them... like, of the 8 paragraphs involved, 2 of them are basic high-level description, 1 of them is a warning against using C code to begin with (sound advice--although a bit off the mark since Inline does any language it is taught to do, not just C/++). Then there is the rest: 3 of the 8 paragraphs are flat out wrong and 2 more don't have the limitations indicated and contradict themselves.

First in says, RubyInline only understands a limited subset of C and C++. The functions you embed can only accept and return arguments of the types char, unsigned, unsigned int, char *, int, long, and unsigned long. If you need to use other types, RubyInline won't be able to automatically generate the wrapper functions. [...]. This is false. Completely and totally false. It isn't even the full list of registered automatically converted types, and since 3.0.0 (released 2003-12-23) there has been public API for registering conversions of your own. Before then it was possible but less easy. Example:

inline(:C) do |builder|
  builder.add_type_converter("VALUE", '', '') # register, but doesn't require conversion
  # ...
end

Second, it goes on to mention that another limitation is that you need to have a complier environment but then says that RubyInline provides inline_package to deal with that... well... is it a limitation or not? Seems they're saying not, except that it is in the list of limitations. Way to put on some negative spin and backpedal one paragraph later. *shrug*

To their credit, Neither Lucas nor Leonard wrote this section. Instead, Garrett Rooney has been given credit for this section, and all other sections for externalized code (except jruby). After doing some googling it looks like Garrett has a stake SWIG, so I have to assume that there is some bias involved.

None of the three sent me the section for review or notified me in any way that this was happening. I'm a bit disappointed, but I guess not that surprised given the publisher. I just wish they'd sent me a draft to review. It would have been so easy to deal with proactively.