Visual Ruby Error when starting vr

Hi Everybody.

I recently installed Visual Ruby after searching for a long time for a
practical UI ruby development environment. My initial install on a PC
with Mint 13 went well after updating Ruby to 1.9 and updating the
links to ruby. Then I moved onto a laptop which is pretty much the same
installation Mint 13 with the same installed files.

After completing the install and trying to start vr from the command
line I get a load of error messages and vr aborts/terminates. I have
attached a copy reported errors. I would appreciate it is some one could
take a look and tell me where I went wrong.

Ok I well not I pacifically solved this by the following method.
It’s not enough to install Ruby 1.9 on it’s own you need a matching set
of gem packaged as well. Many thanks to Shizzle for the installation

The problem seems to be with the way packages are installed on Debian
systems more pacifically Ubuntu/Mint The default Ruby is 1.8 you have
the option to install 1.9 but it seems the only way to be sure you have
the correct version of ruby and gems installed is to follow this script

On Mint the following lines can be copied and pasted into a terminal.

sudo apt-get install ruby1.9.1 ruby1.9.1-dev
rubygems1.9.1 irb1.9.1 ri1.9.1 rdoc1.9.1
build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev

sudo update-alternatives --install /usr/bin/ruby ruby /usr/bin/ruby1.9.1
–slave /usr/share/man/man1/ruby.1.gz ruby.1.gz
–slave /usr/bin/ri ri /usr/bin/ri1.9.1
–slave /usr/bin/irb irb /usr/bin/irb1.9.1
–slave /usr/bin/rdoc rdoc /usr/bin/rdoc1.9.1

choose your interpreter

changes symlinks for /usr/bin/ruby , /usr/bin/gem

/usr/bin/irb, /usr/bin/ri and man (1) ruby

sudo update-alternatives --config ruby
sudo update-alternatives --config gem

now try

ruby --version


It is unfortunate that debian has not already switched to 1.9.x

For things like Ruby, I never wait and rely on the Linux distro to keep
up. I also like(need) to have multiple versions of Ruby available.

Ruby, like many different applications, you can download the source and
configure it to install to an alternate location. This allows you to try
out different versions, without touching the OS install. This works for
most things, I’ll explain here for Ruby.

To keep this separate from the OS, pick a location. Common locations are
things like /opt, /cots, /prod or something. Or keep it in your home
directory. Lets stay with the home dir so you don’t need root to do
anything. make a directory in your home dir called opt.

Grab the Ruby version you want. Lets say the latest release of Ruby

Untar that in your home directory some where. In the directory that is
created from the untar, run

configure --prefix=/home/username/opt/ruby-1.9.2
That will run through configure, hopefully find all it needs.
Now just run “make” Hopefully everything builds.
Now run make install to install it to your area.

It should create

Now, put that version of ruby in your path before anything else. So when
you run “ruby” it grabs that version.

Now when you add gems, or build things like ruby-gnome2, specifically
call out that “ruby” or “gem” binaries(if its first in your path then
you don’t need to give it the absolute path) (run “which ruby” to see
which one you are pointing at)

So if you grabbed the latest ruby-gnome2 release, you would untar that.
cd into that directory and run

/home/username/opt/ruby-1.9.2/bin/ruby extconf.rb
make all
make install

Presto, you just build ruby-gnome2 into your own “sandbox build”

I usually script this, and keep the gems I need installed local. So I
can rebuild a clean ruby install, with all the gems I need. I used gem
fetch to get local copies of the gems I need. I can quickly build 4-5
different builds of ruby, and test them all out with my apps.

The script I have looks something like this(I’m typing this from the top
of my head so I might have a typo somewhere)

set instDir = /home/username/opt/ruby-1.9.2
tar xf rubyDistro.tar.bz2
cd rubyDistro
configure --prefix=$instDir
cd …
$instDir/bin/gem install -l somegem
$instDir/bin/gem install -l somegem2
$instDir/bin/gem install -l somegem3
tar xf rubyGnome2Distro
cd rubyGnome2Distro
$instDir/bin/ruby extconf.rb
make install

The key is I had grabbed the tar files for the ruby distro, and the
ruby-gnome2 distro ahead of time. Including the gems I wanted. I have it
all local(I don’t like to rely on gem to find the latest or whatever is
needed. I really like to be explicit so I know what gems are installed.)

So with the above script, I can have many different ruby installs. I
don’t go grab a new gem or ruby-gnome2 or anything with out playing with
it in a sandbox build.

The main thing I use the OS for is just to use yum/apt to get the base
things I need outside of the Ruby build, like glibc-devel or other
stuff. I like to keep that as part of the OS.

SO I’ve rambled on enough, but it the main thing to keep in mind that
“configure --prefix=somedirecty” can be used for almost everything that
follows the “normal” gnu like build area.

I have gvim, gdb, gnuplot, and lots of other things installed into my
own “opt” area. I like to keep the separate too, not “everything all in
one dir”

So instead of a generic /usr/local, which has bin/man/lib for everyone.
I like to go one level more, specifying the component I am building.
Following my convention above I have something like


Each of those dirs in turn has its bin, man, lib sub dirs. For each
thing I build, I just add that component in my PATH, MANPATH,
LD_LIBRARY_PATH before the OS ones.

it allows you to be nice and specific with different releases of things.
And easily back out of one that “did not go well” as you didn’t pollute
your OS, or a shared /usr/local area.