The Journey to Ruby 1.9

Thanks to some late-night hacking at Boston.rb and plenty of awesome contributors, our gems are now Ruby 1.9 compatible. If you’re wondering what’s different in the newest version of Ruby, check out this great list from Eigenclass.org. Here’s some tips and tricks for those who want to upgrade their own Ruby install and have their gems to be compatible.

Installation

It’s dead easy to run Ruby 1.8.* and 1.9 together on the same machine. Check out how to install it on OSX here, or on Ubuntu here. If you’ve got a great blog post on how to install it on your favorite OS, drop a comment. The most important thing to remember is when you configure your install, add

--program-suffix=1.9

as a flag so all of the binaries end in 1.9. Also, don’t forget to grab the latest RubyGems version. Once you’ve got it downloaded and unpacked, install with:

sudo ruby1.9 setup.rb --format-executable

Make sure to tack on --format-executable whenever you do a gem1.9 install. This will setup executables with the 1.9 suffix, so for instance you can have cucumber and cucumber1.9 living harmoniously together.

Gotchas

Here’s a list of some of the roadbumps we ran into while upgrading our gems, and hopefully you can keep an eye out for them in your code as well.

Files with non-ASCII characters need an encoding set.

The basic solution to this is adding # encoding: utf-8 to the top of your file. Ruby just won’t parse the file without it. Of course, if your file has a different encoding you’ll need use that instead.

lambda is strict about arity

% irb
irb(main):001:0> lambda { 2 + 2 }.call(13)
=> 4
% irb1.9 
irb(main):002:0> lambda { 2 + 2 }.call(13)
ArgumentError: wrong number of arguments (1 for 0)
    from (irb):2:in `call'
    from (irb):2
    from /opt/local/bin/irb1.9:12:in `<main>'

We saw this in Paperclip and Factory Girl. The solution is to make sure you’re calling the lambda with the right amount of arguments, and checking #arity if you have to.

Block-local variables don’t leak scope

This has probably been mentioned on every Ruby 1.9 blog post in existence, but it’s still worth noting.

% irb
irb(main):001:0> item = 1
=> 1
irb(main):002:0> lambda { |item| }.call(2)
=> nil
irb(main):003:0> item
=> 2

% irb1.9
irb(main):001:0> item = 1
=> 1
irb(main):002:0> lambda { |item| }.call(2)
=> nil
irb(main):003:0> item
=> 1

Basically, just make sure that you’re naming things properly. Here’s where we fixed it.

#instance_methods, #methods, and their cousins now return symbols, not strings.

% irb
irb(main):001:0> Object.methods[0..5]
=> ["private_class_method", "inspect", "name", "tap", "clone", "public_methods"]

% irb1.9
irb(main):001:0> Object.methods[0..5]
=> [:allocate, :new, :superclass, :freeze, :===, :==]

The basic fix for this is to tack .map(&:to_s) onto the call. This was happening in quite a few gems.

Array#to_s does more of an inspect instead of its behavior in 1.8

% irb
irb(main):001:0> ["test", nil].to_s
=> "test" 

% irb1.9
irb(main):001:0> ["test", nil].to_s
=> "[\"test\", nil]" 

We saw this in one of Paperclip’s tests. While the new behavior seems to make more sense, just watch out if old code depends on it.

The __FILE__ constant is an absolute path in tests.

This example is a default jeweler generated gem with p __FILE__ in a test:

% rake
(in /Users/qrush/Dev/ruby/test-gem)
/opt/local/bin/ruby -I"lib:lib:test" "/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test-gem_test.rb" 
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
"./test/test-gem_test.rb" 
.
Finished in 0.000371 seconds.

% rake1.9                 
(in /Users/qrush/Dev/ruby/test-gem)
Jeweler (or a dependency) not available. Install it with: sudo gem install jeweler
/opt/local/bin/ruby1.9 -I"lib:lib:test" "/opt/local/lib/ruby1.9/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test-gem_test.rb" 
Loaded suite /opt/local/lib/ruby1.9/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
"/Users/qrush/Dev/ruby/test-gem/test/test-gem_test.rb" 
.
Finished in 0.000728 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

The solution to this was to use File.expand_path to make sure that it worked on both versions. This happened in Paperclip’s tests as well.

Onward!

We test all of our gems on 1.8.7 and 1.9.1 on our Integrity CI server as well, if you’re curious. As of today we’re not yet running full time on 1.9, but we hope to be there soon. The main reason we’re not is because some gems/plugins aren’t compatible, and some hosts don’t support it. We’ll post more articles in the future once we’re running our Rails projects on Ruby 1.9.

The Journey to Ruby 1.9

Thanks to some late-night hacking at Boston.rb and plenty of awesome contributors, our gems are now Ruby 1.9 compatible. If you’re wondering what’s different in the newest version of Ruby, check out this great list from Eigenclass.org. Here’s some tips and tricks for those who want to upgrade their own Ruby install and have their gems to be compatible.

Installation

It’s dead easy to run Ruby 1.8.* and 1.9 together on the same machine. Check out how to install it on OSX here, or on Ubuntu here. If you’ve got a great blog post on how to install it on your favorite OS, drop a comment. The most important thing to remember is when you configure your install, add

--program-suffix=1.9

as a flag so all of the binaries end in 1.9. Also, don’t forget to grab the latest RubyGems version. Once you’ve got it downloaded and unpacked, install with:

sudo ruby1.9 setup.rb --format-executable

Make sure to tack on --format-executable whenever you do a gem1.9 install. This will setup executables with the 1.9 suffix, so for instance you can have cucumber and cucumber1.9 living harmoniously together.

Gotchas

Here’s a list of some of the roadbumps we ran into while upgrading our gems, and hopefully you can keep an eye out for them in your code as well.

Files with non-ASCII characters need an encoding set.

The basic solution to this is adding # encoding: utf-8 to the top of your file. Ruby just won’t parse the file without it. Of course, if your file has a different encoding you’ll need use that instead.

lambda is strict about arity

% irb
irb(main):001:0> lambda { 2 + 2 }.call(13)
=> 4
% irb1.9 
irb(main):002:0> lambda { 2 + 2 }.call(13)
ArgumentError: wrong number of arguments (1 for 0)
    from (irb):2:in `call'
    from (irb):2
    from /opt/local/bin/irb1.9:12:in `<main>'

We saw this in Paperclip and Factory Girl. The solution is to make sure you’re calling the lambda with the right amount of arguments, and checking #arity if you have to.

Block-local variables don’t leak scope

This has probably been mentioned on every Ruby 1.9 blog post in existence, but it’s still worth noting.

% irb
irb(main):001:0> item = 1
=> 1
irb(main):002:0> lambda { |item| }.call(2)
=> nil
irb(main):003:0> item
=> 2

% irb1.9
irb(main):001:0> item = 1
=> 1
irb(main):002:0> lambda { |item| }.call(2)
=> nil
irb(main):003:0> item
=> 1

Basically, just make sure that you’re naming things properly. Here’s where we fixed it.

#instance_methods, #methods, and their cousins now return symbols, not strings.

% irb
irb(main):001:0> Object.methods[0..5]
=> ["private_class_method", "inspect", "name", "tap", "clone", "public_methods"]

% irb1.9
irb(main):001:0> Object.methods[0..5]
=> [:allocate, :new, :superclass, :freeze, :===, :==]

The basic fix for this is to tack .map(&:to_s) onto the call. This was happening in quite a few gems.

Array#to_s does more of an inspect instead of its behavior in 1.8

% irb
irb(main):001:0> ["test", nil].to_s
=> "test" 

% irb1.9
irb(main):001:0> ["test", nil].to_s
=> "[\"test\", nil]" 

We saw this in one of Paperclip’s tests. While the new behavior seems to make more sense, just watch out if old code depends on it.

The __FILE__ constant is an absolute path in tests.

This example is a default jeweler generated gem with p __FILE__ in a test:

% rake
(in /Users/qrush/Dev/ruby/test-gem)
/opt/local/bin/ruby -I"lib:lib:test" "/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test-gem_test.rb" 
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
"./test/test-gem_test.rb" 
.
Finished in 0.000371 seconds.

% rake1.9                 
(in /Users/qrush/Dev/ruby/test-gem)
Jeweler (or a dependency) not available. Install it with: sudo gem install jeweler
/opt/local/bin/ruby1.9 -I"lib:lib:test" "/opt/local/lib/ruby1.9/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test-gem_test.rb" 
Loaded suite /opt/local/lib/ruby1.9/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
"/Users/qrush/Dev/ruby/test-gem/test/test-gem_test.rb" 
.
Finished in 0.000728 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

The solution to this was to use File.expand_path to make sure that it worked on both versions. This happened in Paperclip’s tests as well.

Onward!

We test all of our gems on 1.8.7 and 1.9.1 on our Integrity CI server as well, if you’re curious. As of today we’re not yet running full time on 1.9, but we hope to be there soon. The main reason we’re not is because some gems/plugins aren’t compatible, and some hosts don’t support it. We’ll post more articles in the future once we’re running our Rails projects on Ruby 1.9.

The Journey to Ruby 1.9

Thanks to some late-night hacking at Boston.rb and plenty of awesome contributors, our gems are now Ruby 1.9 compatible. If you’re wondering what’s different in the newest version of Ruby, check out this great list from Eigenclass.org. Here’s some tips and tricks for those who want to upgrade their own Ruby install and have their gems to be compatible.

Installation

It’s dead easy to run Ruby 1.8.* and 1.9 together on the same machine. Check out how to install it on OSX here, or on Ubuntu here. If you’ve got a great blog post on how to install it on your favorite OS, drop a comment. The most important thing to remember is when you configure your install, add

--program-suffix=1.9

as a flag so all of the binaries end in 1.9. Also, don’t forget to grab the latest RubyGems version. Once you’ve got it downloaded and unpacked, install with:

sudo ruby1.9 setup.rb --format-executable

Make sure to tack on --format-executable whenever you do a gem1.9 install. This will setup executables with the 1.9 suffix, so for instance you can have cucumber and cucumber1.9 living harmoniously together.

Gotchas

Here’s a list of some of the roadbumps we ran into while upgrading our gems, and hopefully you can keep an eye out for them in your code as well.

Files with non-ASCII characters need an encoding set.

The basic solution to this is adding # encoding: utf-8 to the top of your file. Ruby just won’t parse the file without it. Of course, if your file has a different encoding you’ll need use that instead.

lambda is strict about arity

% irb
irb(main):001:0> lambda { 2 + 2 }.call(13)
=> 4
% irb1.9 
irb(main):002:0> lambda { 2 + 2 }.call(13)
ArgumentError: wrong number of arguments (1 for 0)
    from (irb):2:in `call'
    from (irb):2
    from /opt/local/bin/irb1.9:12:in `<main>'

We saw this in Paperclip and Factory Girl. The solution is to make sure you’re calling the lambda with the right amount of arguments, and checking #arity if you have to.

Block-local variables don’t leak scope

This has probably been mentioned on every Ruby 1.9 blog post in existence, but it’s still worth noting.

% irb
irb(main):001:0> item = 1
=> 1
irb(main):002:0> lambda { |item| }.call(2)
=> nil
irb(main):003:0> item
=> 2

% irb1.9
irb(main):001:0> item = 1
=> 1
irb(main):002:0> lambda { |item| }.call(2)
=> nil
irb(main):003:0> item
=> 1

Basically, just make sure that you’re naming things properly. Here’s where we fixed it.

#instance_methods, #methods, and their cousins now return symbols, not strings.

% irb
irb(main):001:0> Object.methods[0..5]
=> ["private_class_method", "inspect", "name", "tap", "clone", "public_methods"]

% irb1.9
irb(main):001:0> Object.methods[0..5]
=> [:allocate, :new, :superclass, :freeze, :===, :==]

The basic fix for this is to tack .map(&:to_s) onto the call. This was happening in quite a few gems.

Array#to_s does more of an inspect instead of its behavior in 1.8

% irb
irb(main):001:0> ["test", nil].to_s
=> "test" 

% irb1.9
irb(main):001:0> ["test", nil].to_s
=> "[\"test\", nil]" 

We saw this in one of Paperclip’s tests. While the new behavior seems to make more sense, just watch out if old code depends on it.

The __FILE__ constant is an absolute path in tests.

This example is a default jeweler generated gem with p __FILE__ in a test:

% rake
(in /Users/qrush/Dev/ruby/test-gem)
/opt/local/bin/ruby -I"lib:lib:test" "/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test-gem_test.rb" 
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
"./test/test-gem_test.rb" 
.
Finished in 0.000371 seconds.

% rake1.9                 
(in /Users/qrush/Dev/ruby/test-gem)
Jeweler (or a dependency) not available. Install it with: sudo gem install jeweler
/opt/local/bin/ruby1.9 -I"lib:lib:test" "/opt/local/lib/ruby1.9/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test-gem_test.rb" 
Loaded suite /opt/local/lib/ruby1.9/gems/1.9.1/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
"/Users/qrush/Dev/ruby/test-gem/test/test-gem_test.rb" 
.
Finished in 0.000728 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

The solution to this was to use File.expand_path to make sure that it worked on both versions. This happened in Paperclip’s tests as well.

Onward!

We test all of our gems on 1.8.7 and 1.9.1 on our Integrity CI server as well, if you’re curious. As of today we’re not yet running full time on 1.9, but we hope to be there soon. The main reason we’re not is because some gems/plugins aren’t compatible, and some hosts don’t support it. We’ll post more articles in the future once we’re running our Rails projects on Ruby 1.9.

Article:Kernel Comparison of three Quasi-Unix OS

This article briefly examines and compares the kernels of the three most widely used quasi-Unix operating systems using three axes of comparison: efficiency, evolvement, and user friendliness. The operating systems compared (kernel only) are: OpenSolaris, Windows Vista, and Linux 2.6. By Dingze Zhu

Should We Rely on Language Constraints or Responsibility?

Bruce Eckel, Michael Feathers, Niclas Nilsson, Keith Braithwaite, and others on the question: should languages be fully flexible, allowing the developers to tweak them as they like, and trusting they will be responsible in their work, or should there be clear constraints set in the language from its design phase to avoid mistakes that create bad code, hard to maintain or to read? By Abel Avram

My Apprenticeship - Friday, July 16, 2004

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

I remember being pretty worked up about asking Object Mentor for a day off so I could get my passport. They were very cool about it. On the other hand I was working for free that summer. And by working I mean floundering. They were probably excited to have a day where they didn't have to listen to me complain about a '5 minute install' all day long.

The wise Latina comment in historical perspective

I’ve watched no more of the Sotomayor hearings than has happened to be on while I’ve waited for the guy behind the counter to toast my bagel, and things like that. I don’t see much point in watching them, since it’s pretty easy to predict what her critics are going to ask her and say about her, and not terribly interesting to hear her answers.

But I do want to say something about this “wise Latina” thing, if I can do so without boring myself as well as you to death.

With very few exceptions, all Supreme Court justices, ever, have been white men. So have most other judges in the U.S. That means that someone, somewhere along the line, felt that white men make wiser decisions than people who are not white men. Maybe closer to “everyone” than “someone”, in fact.

White male jurists never have to say anything public to the effect that white males as wiser, as jurists, than people who aren’t white males, because it’s been said for them. It’s been said by virtually every President who has made judicial appointments and nominations, every Senator on whom the strangely homogenous pattern has not weighed heavily, and every citizen who never considered withholding a vote from the perpetrators of this centuries-long exercise in exclusion.

In short, the entire history of the Supreme Court and much of the rest of the judiciary amounts to a sustained assertion that white men make wiser decisions than anyone else.

So along came Sotomayor, and expressed a different opinion. She expressed an opinion that was not the opinion on which the entire history of the Supreme Court has been predicated. She espoused the belief that white men do not, in every imaginable case, make wiser judges.

Well!

How dare she?!

Doesn’t she realize that The Universal Opinion on this subject has already been established?

Of course it’s the same old thing. The belief that white males are wiser is so widespread, so ingrained, so taken for granted, that it seems natural. You don’t have to think about it; your thinking has been done for you. And you don’t have to be so gauche as to say that you believe it, because as long as you don’t saying anything, it will be assumed that that’s what you think.

All Sotomayor did was to respond. She was responding to history. History was saying—loudly, repeatedly, in chorus echoing down the centuries—that white men make wiser jurists. Sotomayor said: maybe not, under some circumstances.

That’s all.

Think of it this way. Sotomayor walks down the street every day, her whole life, and every couple of blocks, somebody says to her: White male jurists make wiser decisions than anyone else. Senators say it; Supreme Court justices say it. Citizens say it; Presidents say it.

After a lifetime of that, Sotomayor says: well, not necessarily.

And everyone gets mad at her.

The every-couple-of-blocks thing represents about one millionth of one percent of what Sotomayor, and the rest of us, have actually had communicated to us over our lifetimes. So why the hell shouldn’t she respond? And why are people treating her like Oliver Twist asking for more gruel?

A few Hoptoad UI adjustments

Since we launched the Hoptoad redesign we’ve been discussing ways to improve usability which has lead to a few changes as well as some new features. Below is an overview of some of these changes:

Error Index

Error show page

1. Sensible left column: We’ve limited the information on the left to be more global in nature.
2. Error message: We moved the error message to the main column and grouped it with similar information. This allows it to display in a full and unencumbered form.
3. Navigating errors: You can now navigate through similar errors using these handy buttons.
4. Link to GitHub: This button will take you directly to the file in question if it’s available in GitHub.

We’re continuing with improvements throughout the app in order to make daily use of Hoptoad as pleasant as possible. As always, thanks for riding the toad.

A few Hoptoad UI adjustments

Since we launched the Hoptoad redesign we’ve been discussing ways to improve usability which has lead to a few changes as well as some new features. Below is an overview of some of these changes:

Error Index

Error show page

1. Sensible left column: We’ve limited the information on the left to be more global in nature.
2. Error message: We moved the error message to the main column and grouped it with similar information. This allows it to display in a full and unencumbered form.
3. Navigating errors: You can now navigate through similar errors using these handy buttons.
4. Link to GitHub: This button will take you directly to the file in question if it’s available in GitHub.

We’re continuing with improvements throughout the app in order to make daily use of Hoptoad as pleasant as possible. As always, thanks for riding the toad.