The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
RubyInline Myths

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Ryan Davis

Posts: 651
Nickname: zenspider
Registered: Oct, 2004

Ryan Davis is a ruby nerd.
RubyInline Myths Posted: Sep 1, 2006 1:44 PM
Reply to this message Reply

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

Advertisement

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.

Read: RubyInline Myths

Topic: Nginx & Mongrel Clusters tutorial for Ruby on Rails deployment Previous Topic   Next Topic Topic: Sloop: Sublanguage for Object Orientation with Prototypes

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use