Hi i’m new here and new with Ruby. I just start to learn Ruby and Ruby
on Rails. My question is wich between Ruby or JRuby should i learn. What
the diffrence and why one and not the other one. Thanks 
Martin L’ecuyer wrote:
Hi i’m new here and new with Ruby. I just start to learn Ruby and Ruby
on Rails. My question is wich between Ruby or JRuby should i learn. What
the diffrence and why one and not the other one. Thanks
For learning, there’s not a whole lot of difference. JRuby is almost
completely compatible with Ruby 1.8.6, so what you learn on one should
generally apply to the other.
- Charlie
Hi Martin.
Don’t look at is as “JRuby versus Ruby”, so much as two different
implementations of the same thing. I’d focus on using whichever is best
suited for your computing environment. If you have no limitations that
would
prevent you from running plain old Ruby, I’d stick with that for the
time
being.
James
On Tue, Apr 21, 2009 at 4:39 PM, James H. [email protected]
wrote:
This is a tough call, I would rather learn Ruby1.9, but that will not
be such a big difference at the beginning.
When you start playing around JRuby will have the advantage that you
can test 1.8 code and 1.9 code by simply providing the --1.9 option to
the interpreter.
Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.
HTH
Robert
–
Si tu veux construire un bateau …
Ne rassemble pas des hommes pour aller chercher du bois, préparer des
outils, répartir les tâches, alléger le travail… mais enseigne aux
gens la nostalgie de l’infini de la mer.
If you want to build a ship, don’t herd people together to collect
wood and don’t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.
On Tuesday 21 April 2009 09:48:47 Robert D. wrote:
On Tue, Apr 21, 2009 at 4:39 PM, James H. [email protected]
Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.
It really wasn’t, for me. The easiest way is to simply give the
executables a
suffix – irb1.9 vs irb. And I don’t know that typing “irb1.9” is harder
than
“jruby --1.9”.
On Wed, Apr 22, 2009 at 10:43 PM, David M. [email protected]
wrote:
On Tuesday 21 April 2009 09:48:47 Robert D. wrote:
On Tue, Apr 21, 2009 at 4:39 PM, James H. [email protected]
Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.
It really wasn’t, for me. The easiest way is to simply give the executables a
suffix – irb1.9 vs irb. And I don’t know that typing “irb1.9” is harder than
“jruby --1.9”.
At first I thought it was a brilliant idea, so I did it but gem1.9
install bombed because it did not find gem, I do not think that I did
anything stupid.
Anyway I have opted for ruby1.9 into /usr/local/bin and jruby in my
home dir with an alias to $JRUBY_HOME/bin/jruby
and shell functions for jgem, jrake, jirb etc.
That is painless and good enough for me.
BTW I spent a day of installing and reinstalling ruby1.9 and ruby1.8
on the same machine and nothing I tried made them coexist without
major shell scripts for switching. As those might not scale to
changes I gave up on it, but maybe I was too tired and missed
something stupid.
Cheers
Robert
On Wed, Apr 22, 2009 at 3:19 PM, Robert D. [email protected]
wrote:
BTW I spent a day of installing and reinstalling ruby1.9 and ruby1.8
on the same machine and nothing I tried made them coexist without
major shell scripts for switching.
?? When I have multiple versions of anything on one system, I just
install each to its own directory, and then have a file with something
like, e.g. file named ~/187
export RUBY_HOME=/usr/local/ruby1.8.7
export PATH=$RUBY_HOME/bin:$PATH
:: and then I just type ‘. 187’ – tickety-boo and bob’s yr uncle.
Never had a problem from using that approach.
FWIW,
On 22 avr. 09, at 16:43, David M. wrote:
“jruby --1.9”.
Probably the installation difference is minor if you just want to
learn and experiment. It’s more of an issue if you seriously want
to adopt ruby 1.8 and 1.9 on many machines, different platforms, and
critical applications. Then you have to be more careful with Ruby
1.8 and 1.9. Different package managers and installers are going to
give you different snapshots. You’ll want to be sure you have some
kind of system in place for managing, updating and backing off all
the different permutations so that your apps will be reliable.
If Ruby 1.8 and 1.9 source came in a version control system such that
it was quick and easy to retrieve specific versions that would
probably help a lot. Then you could try various versions without
worrying too much if there are any issues and you could probably give
good specific information about problems to ruby developers so they
can fix them.
Robert D. wrote:
install bombed because it did not find gem, I do not think that I did
anything stupid.
I’ve gone the ‘–program-suffix=19’ route, just to play with ruby19, and
not had a problem, but I’ve avoided using gem19.
What happens if I do
gem19 install rake
for example? Well, it overwrites my old rake, and the new rake has a
hashbang line that invokes ruby19. Kaboom.
Maybe gem install should be aware of things like program-suffix in
rbconfig, and use them?
On Thu, Apr 23, 2009 at 12:35 AM, Joel VanderWerf
[email protected] wrote:
Maybe gem install should be aware of things like program-suffix in rbconfig,
and use them?
42+
R.
On Wed, Apr 22, 2009 at 3:37 PM, Robert D. [email protected]
wrote:
I had absolutely no problem running Ruby this way. The problem I had
is with gems.
Just out of curiousity, what kind of problem?
But maybe all those approaches are sound, I am notorious for
“forgetting” things, too bad one cannot do
Test Driven Installation
Yes, well, there is the issue of forgetting to install particular gems
in
the different versions – but the error messages lead me to that “fix”
eventually 
On Thu, Apr 23, 2009 at 12:31 AM, Hassan S.
[email protected] wrote:
export RUBY_HOME=/usr/local/ruby1.8.7
I had absolutely no problem running Ruby this way. The problem I had
is with gems.
But maybe all those approaches are sound, I am notorious for
“forgetting” things, too bad one cannot do
Test Driven Installation
R
–
Si tu veux construire un bateau …
Ne rassemble pas des hommes pour aller chercher du bois, préparer des
outils, répartir les tâches, alléger le travail… mais enseigne aux
gens la nostalgie de l’infini de la mer.
If you want to build a ship, don’t herd people together to collect
wood and don’t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.
On Wed, Apr 22, 2009 at 6:32 PM, Robert D. [email protected]
wrote:
Joel explained it better than I did, it comes down to the fact that
gem does not know about the suffix.
Ah, that’s why the suffix thing makes no sense to me – if you use
the default names for everything and set your path to the desired
version, everything works just fine, e.g.
/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby
and so on, jruby installations as well.
On Thu, Apr 23, 2009 at 4:10 AM, Hassan S.
[email protected] wrote:
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/rubyand so on, jruby installations as well.
Hassan S. ------------------------ [email protected]
hmm that indeed looks promising, I must have hosed things with links,
thanks for sharing!
Robert
–
Si tu veux construire un bateau …
Ne rassemble pas des hommes pour aller chercher du bois, préparer des
outils, répartir les tâches, alléger le travail… mais enseigne aux
gens la nostalgie de l’infini de la mer.
If you want to build a ship, don’t herd people together to collect
wood and don’t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.
On Thu, Apr 23, 2009 at 12:56 AM, Hassan S.
[email protected] wrote:
On Wed, Apr 22, 2009 at 3:37 PM, Robert D. [email protected] wrote:
I had absolutely no problem running Ruby this way. The problem I had
is with gems.Just out of curiousity, what kind of problem?
Joel explained it better than I did, it comes down to the fact that
gem does not know about the suffix.
R.
Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.
It is a breeze if you use Application-like approaches (like on
Gobolinux). I still, up today, wonder why there are problems with Mac OS
X + ruby.
Anyway, if you follow the FHS approach then for sure things will get
messy, because the FHS itself encourages bad practise.
Just look at the workaround provided before:
/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby
It uses versioned directories already. When will people realize that the
FHS in itself does not evolve in any way?
I do however think that these directories look ugly, and wont be in the
default search path anyway. Gobolinux would use /Programs/Ruby/1.8.6 for
this, Heretix/Rubyx did use /pkg/ruby/1.9.6 (unfortunately this
distribution died…), what PC-BSD is using I dont know but I think /pkg
too - not sure here.
that’s why the suffix thing makes no sense to me
Personally, I never understood why i.e. debian makes a symlink to
ruby1.8 (or the other way around)
Versioning binaries is another hack to work around what the FHS imposes
on you - else, there would be no need for symlinking binary versions at
all, no?
PS: Gems, even if they work nicely, will forever be dependent on the
FHS, for as long as distributions use it. And thus, gems will forever
have those problems which popup again and again. (rubygems are nice
though, i just think that they should be an integral part of ruby,
without the need for require ‘rubygems’ before any specific gem is
required. This explicit requiring for rubygems is a small design
limitation imho.)
On Wednesday 22 April 2009 17:35:27 Joel VanderWerf wrote:
Maybe gem install should be aware of things like program-suffix in
rbconfig, and use them?
Ideally, it should. However, you can do this:
gem19 install rake --format-executable
Then it will install rake19.
I actually don’t use that, because I got tired of typing it all the
time. I
instead installed 1.8 and 1.9 in separate locations, and wrote a few
wrapper
scripts to set up PATH and RUBYLIB appropriately.
On Thu, Apr 23, 2009 at 4:43 AM, Marc H. [email protected]
wrote:
Just look at the workaround provided before:
Never thought of it as a ‘workaround’ – just the way to install
multiple
versions of anything
/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby
I do however think that these directories look ugly, and wont be in the
default search path anyway.
Well, “ugly” is in the eye of the beholder, certainly, but I like being
able
tols /usr/local and see at a glance what versions of what are
installed.
And “not in the default path” is the whole point – the version
available
to a given shell instance is /only/ what you explicitly put in your
path.
YMMV,
On Wed, Apr 22, 2009 at 6:35 PM, Joel VanderWerf
[email protected] wrote:
It really wasn’t, for me. The easiest way is to simply give the
I’ve gone the ‘–program-suffix=19’ route, just to play with ruby19, and not
had a problem, but I’ve avoided using gem19.What happens if I do
 gem19 install rake
for example? Well, it overwrites my old rake, and the new rake has a
hashbang line that invokes ruby19. Kaboom.
The shell script at the url above seems to be working well for me.
Best,
Michael G.