Forum: Ruby-Gnome 2 Visual Ruby Error when starting vr

6aa0eba42612dd45c9bf7cbcc08d5fa2?d=identicon&s=25 Ray Ward (rayfward)
on 2012-08-19 21:43
Attachment: visualruby.txt (7 KB)
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.
6aa0eba42612dd45c9bf7cbcc08d5fa2?d=identicon&s=25 Ray Ward (rayfward)
on 2012-08-26 12:25
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
400 \
         --slave   /usr/share/man/man1/ruby.1.gz ruby.1.gz \
                        /usr/share/man/man1/ruby1.9.1.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

4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2012-08-26 12:37
It is unfortunate that debian has not already switched to 1.9.x
C53e81f5d7c781c6dc3979c4ce888706?d=identicon&s=25 Grant Schoep (matobinder)
on 2012-08-26 21:11
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

cd <untarred ruby-gnome2 area>
/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.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.