Thoughts / Misc: September 2006 Archives

Finished my talk and am winding down. Not bad at all for an unrehearsed talk. I'll be giving it again tomorrow at limewire so I should have plenty of practice for ajaxworld next week. YAY!

ok. dying now... thud

I'll be in NYC for the 26th! I'm flying out to meet the fabulous Ms. Amy Hoy to interview at Limewire. I'll be missing the Seattle.rb meeting, but going to my first NYC.rb meeting!

While I'm in the city I hope to hang out with some of the NYC.rb crew, have some arepas, and generally have a good time. What else should I do? I get in way too early.

I've said this before but I was lax in enforcing it for rubyforge 0.2.0:

ALWAYS deploy from a manifest file!

Specifically Dir.glob with ** is evil. Even * is evil.

That said, rubyforge now packages from a hand-created manifest file and the rdoc is a bit cleaner.

sudo gem update rubyforge

I'm proud to announce that codeforpeople's rubyforge 0.2.0 has been released! This release marks a massive revamp to rubyforge splitting the previous command-line script into a script and library with unit tests. Makeing the system now able to be used directly from Rakefiles and other deployment scripts!

We've extended the command set and added semi-automatic configuration of groups, projects, and releases. We've also added the ability to add files to a release.

We have a lot of plans for this library. Next on the list is to be able to specify multiple files to release all at once, error checking, and a much more powerful configuration system.

Editorial:

This is sooo going to make my deployment life easier! I'm planning on doing a release per day for this week (with this release counting as Wednesday's release).

Eventually I'd like you to be able to do this:

% echo "group: seattlerb
project: ringy_dingy" > .rubyforge.yml
% rake test clean package
% rubyforge release 1.2.3 pkg/*

For now I'm quite happy with:

% rake test clean package
% rubyforge add_release seattlerb ringy_dingy 1.2.3 pkg/*.gem
% rubyforge add_file seattlerb ringy_dingy 6929 pkg/*.tgz

The only real PITA is getting that release ID by hand. That is next on my list.

Tomorrow should be a release of RubyInline. Long overdue.

I spent too many of the last 36 hours working on my presentation coming up in October. It is done, and I'd like to take a breather now. Oh, and by the way, I'll be giving a talk at AJAXWorld in Santa Clara on October 3, 2006! :P

What? The title? You already know it:

"Electric Kool-aid Acid Testing"

So, if you wanted to see that talk, here is your chance.

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.