Welcome to the list of Frequently Asked Questions on the ruby-talk mailing list ! Feel free to add to it!

What are the ruby-talk best practices/guidelines?
How do I convert a ruby script into a distributable executable?
What is the best Ruby GUI framework?
What is the best editor for Ruby?
Ruby should do X!
Why does ruby’s comparison with floats fail?
gems fail to load in 1.9.1
unicode characters are not found by \w in 1.9

• Some Ruby talk Posting Best Practices

• You will most likely get a more qualified response from the project-specific mailing lists or forums than on the ruby-talk mailing list. The ruby-talk mailing list focuses on the Ruby programming language itself. Check the projects homepage for details about where to get help.

• Ocra is often recommended for Windows users 1
• The older way is “rubyscript2exe”, but this project is not updated for newer Ruby versions.
• exerb is also another windows packager.
• All the cross platform ones also work with doze.

• AllInOneRuby
• “crate” is cross platform (and often recommended for linux) [1 2].
• rawr is a distributor for jruby.
• rb2exe
• Source code: If you just wish to distribute your ruby code to other developers then you could also distribute it as a gem.
• Shoes (somewhat unmaintained GUI framework) allows packaging distributables for each OS.

• Ruby Installer is the successor to the One-Click Installer. Release candidates of newer Ruby versions are available for download. While they are not directly compatible with the old One-Click Installer, they are generally stable for most uses.

• see this thread

here is a list comparing some

• See the Ruby GUI comparison

• Please read this post for an intro to writing RCR’s. I would note that the latest way to submit an RCR is to just submit it to the ruby-core mailing list and/or create a RedMine ticket. Typically I would recommend discussing it on ruby-talk first, as well.

Instructions on how to submit a patch

• See Closures in Ruby

Sometimes floats in Ruby do funky things.

Example of odd behavior:

>> (2.0-1.1) == 0.9
=> false

Why? Because floats are by default slightly imprecise

This is not Ruby’s fault, but floating point numbers in general suffer from this type of rounding error, because they’re limited to x number of bytes, and, in general, cannot store decimal number perfectly.

Your options when you run into this:

• compare values by delta, example (from test/unit framework):

  assert_in_delta((1.1-0.9), 0.2, 0.0001) # passes

• use BigDecimal

>> require 'bigdecimal'
>> (BigDecimal.new("1.1") - BigDecimal.new("0.9")) == 0.2
=> true

• use Rational

>> a = Rational(11, 10) - Rational(9, 10) # 11/10 - 9/10
=> (1/5)
>> a == 0.2
=> true

What’s really going on here:

>> 1.1
=> 1.1 # in reality this probably doesn't equal exactly 1.1 deep down--but it's equal to 1.1's default so ruby 1.9.2 will display it as 1.1
> 0.9
=> 0.9
> 1.1-0.9
=> 0.20000000000000007 # now ruby 1.9.2 notices that "this 0.2 is not the same as the default float for 0.2" so it displays its full version to remind us of this fact.

How can I make them pretty (misleadingly pretty) again, in 1.9.2+ like they used to be?

class Float
  def pretty_s
    num = "%.12g" % self
    num.sub!(/\.(.*?)0+$/,".$1")
    # might be like 2. at this point
    num = num[0..-2] if num[-1] == '.'
    num
  end
end
p 1.1-0.9 # >> 0.20000000000000007
p (1.1-0.9).pretty_s # >> "0.2"
p 2.0.pretty_s # >> "2"

http://coderrr.wordpress.com/2009/12/22/get-arbitrarily-precise-bigdecimals-in-ruby-for-just-one-extra-character/ os a clever trick to use BigDecimal more easily.

• classic article
• wikipedia

Basically at a certain patch level of 1.9.1, \w was set to no longer match unicode characters, because the core developers were concerned that this was not what people expected from \w.

see this link

With 1.9.0 and 1.9.1, gem uses “gem_prelude” to load files from gems.
It basically (pre) loaded the “lib” paths of each highest numbered gem to your require path.
This sped things up quite a bit for startup time, but introduced a few subtle bugs with rubygems so was set to be used far less in 1.9.2.

In 1.9.2, it does not preload lib paths. Instead, if you ever do a require 'rubygems' it reverts back to the normal “full” rubygems (adding lib paths “on demand”). In 1.9.1 it also reverts to “full” rubygems, but only if you ever use a gem specific constant or method, like Gem.xxx or Gem::Dependency, and it leaves the load path full of the old libs.

In 1.9.1, if you want to avoid using the somewhat buggy gem_prelude, then run your script like ruby --disable-gems script_name.rb and include the require 'rubygems' line in your script, or upgrade to 1.9.2

Note: this is not the first ruby faq. Take a step back in history and see the original