Developer Day Notes 4: A Ruby 1.9 Case Study on Upgrading RCov
Ruby is young and maturing, Ruby 1.9 will be a major improvement
(especially in speed). You’ll need to maintain separate environments for
Ruby 1.8 and Ruby 1.9 to be able to start playing.
Demo of shell scripts to user_ruby_191 or user_jruby. One-command
switch of the PATH, GEM_HOME, and GEM_PATH environment variables.
RCov tells you C0 code coverage of your test suite.
To know if things will work in Ruby 1.9, just pick the project and run
its test. It will almost certainly break.
RCov’s C extension was its claim to fame, made it 200-300x faster than
pure Ruby tools. But reaching into Ruby internals means the upgrade to
1.9 was especially hairy.
Remove of node.h and env.h is/was a big problem as rcov relied heavily
The easy parts are that len and ptr are no longer members of array and
string, but there are new macros… but backwards compatibility is now a
pain in the ass, so you’ll have to create a wrapping macro, or separate
code branches and let mkmf do the work.
RCov looks like an old gem. Maybe it could use Jeweler, but right now it
needs to work with 1.9.
So, back to the Ruby side.
First, small things:
Use ‘then’ instead of : in case statements.
String no longer has to_a (use lines.to_a) or several other shortcuts.
The main RCov binary is basically a big option parser.
‘gem install rcov’ is the abandoned Rubyforge, but ‘gem install
relevance-rcov’ from GitHub is the current version.
lowlevel.rb is a Ruby-only proof of concept so that they know code
coverage will work and they’re using it as a guide for developing the C
C extensions will be your timesink. Most of the Ruby changes are very
straightforward. “rexml is no longer your friend” – it’s less flexible
and hard to make backwards-compatible libs, but much faster.
zsh scripts at github.com/spicycode/spicy-config