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.
I think it would be great if all publishers sent an advance copy to any developers mentioned in their books.
And, a final printed copy of the book would not be a bad idea, either.
Most publishers take 90% of the profits from a book, so a little kickback to the open source community that makes their books possible would be appreciated.
Yeah, they should have at least given you a heads up. Just common courtesy dictates that if you're going to comment (or publish!) about someone's software, you should at least get a blessing on the manuscript and get some feedback. Especially annoying is that they got a SWIG guy to write the RubyInline section. What the...!?? That would be like getting a Java guy to write a section on Parrot in a perl6/pugs book. Seriously. WTF is up with that!
For what it's worth, I got the list of types right out of the README.txt in RubyInline 3.5.0. If there is more support, I'm sorry I missed it. As for any other errors I made, I'm sure Lucas and Leonard would be happy to accept error reports correcting them.
As for me being a SWIG person, that's pretty funny, as I honestly lean more towards writing ruby extensions by hand than using either SWIG or RubyInline. I know just enough SWIG to get by, and when I do have to mess with it as often as not I end up pissed off because it's such a pain in the ass. If google gives you hits about me and SWIG, it's only because I work on Subversion and many of the Subversion language bindings are written using SWIG.
Sorry, Garrett, I was probably a bit reactionary in my comment; no offense was intended. I do think the publisher should have at leat got some input from Mr. Davis before they went to print; but I retract my statement regarding you being "SWIG guy".