I’d like to start using Ruby 1.9 more often. Often I could use the
extra performance. However, I’m still concerned about bugs and
incompatibilities. Is there a practical way to use 1.9 in such a
way that these potential problems are minimized? I mostly use Linux
and OSX, and on rare occasions Windows.
On Thu, Apr 16, 2009 at 7:52 PM, Juan Z. [email protected]
wrote:
I’d like to start using Ruby 1.9 more often. Often I could use the extra
performance. However, I’m still concerned about bugs and incompatibilities.
Is there a practical way to use 1.9 in such a way that these potential
problems are minimized? I mostly use Linux and OSX, and on rare occasions
Windows.
Sure, install JRuby(1) and run it with --1.9 switch ;). Well if this
is not an option you can do something painful like I did, I installed
1.9.1, 1.8.7 and 1.8.6 into $HOME/opt and have scripts that relink
those directories to $HOME/ruby and put $HOME/ruby/bin into my PATH.
However I have issues with gems and my only stable Ruby release is
JRuby. I have aliases to all Ruby tools of JRuby like e.g. jgems,
jspec, jri, jirb… not to get completely confused, which I am
anyway…
(1) Using JRuby will probably give you the extra speed for 1.8.6 too 
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 Apr 16, 2009, at 12:52 PM, Juan Z. wrote:
I’d like to start using Ruby 1.9 more often. Often I could use the
extra performance. However, I’m still concerned about bugs and
incompatibilities. Is there a practical way to use 1.9 in such a
way that these potential problems are minimized? I mostly use Linux
and OSX, and on rare occasions Windows.
One easy way is just to install 1.9 separate from your 1.8 install.
You can do that by feeding the configure script a --program-suffix=19
option which would add a 19 to the end of all the executables it
installs. Thus you would use ruby19, irb19, etc.
Hope that helps.
James Edward G. II
On Thu, Apr 16, 2009 at 8:32 PM, James G. [email protected]
wrote:
ows.
One easy way is just to install 1.9 separate from your 1.8 install. You can
do that by feeding the configure script a --program-suffix=19 option which
would add a 19 to the end of all the executables it installs. Thus you
would use ruby19, irb19, etc.
OMG why did I not ask you, or err, reading ./configure --help a little
bit more carefully, before installing!!!
This avoids probably the kind of compatibility problems I ran into.
Juan, by all means, follow James’ approach if you cannot go with
JRuby.
R.
On 16 avr. 09, at 14:32, James G. wrote:
program-suffix=19 option which would add a 19 to the end of all the
executables it installs. Thus you would use ruby19, irb19, etc.Hope that helps.
James Edward G. II
I think that’s a great way to keep ruby 1.9 separate from 1.8. I’m
still not sure how to manage various versions of 1.9 across various
operating systems.
On Apr 16, 2009, at 7:52 PM, Juan Z. wrote:
I’d like to start using Ruby 1.9 more often. Often I could use the
extra performance. However, I’m still concerned about bugs and
incompatibilities. Is there a practical way to use 1.9 in such a
way that these potential problems are minimized? I mostly use Linux
and OSX, and on rare occasions Windows.
I have installed several Ruby versions in the following directories
(using --prefix):
/usr/local/pkgs/ruby-1.8.5-p231
/usr/local/pkgs/ruby-1.8.6-p368
/usr/local/pkgs/ruby-1.8.7-p72
/usr/local/pkgs/ruby-1.9.1-p0
I have /usr/local/pkgs/ruby-current which is a symlink to one of the
above directories. I also have a script that changes the symlink so I
can switch to any version of Ruby at any time. Lastly, I have /usr/
local/pkgs/ruby-current/bin in my $PATH.
–program-suffix is IMHO not a great solution. I prefer keeping the
different Ruby versions entirely separate (no shared gems for
instance). In addition, some applications that use Ruby don’t work
well with a Ruby installation that has a custom program suffix
(NetBeans jumps to mind).
Regards,
Denis
On 16 avr. 09, at 16:44, Denis D. wrote:
(using --prefix):
–
Denis D.
[email protected]
I hadn’t realized that different gems might not like --program-
suffix. That’s good to know. If that’s so then the symlink method
seems more robust.
I’m still not sure how I’d maintain those different version
efficiently across different machines. I don’t want to introduce
too much maintenance or too much testing perplexity. It seems like
I’d either have to carefully keep track of tarballs (store, backup,
catalog) or do checkouts for each of the separate versions. Every
update of a separate tag is then another download for every machine
and even then it’s difficult to be sure that a particular tag hasn’t
actually changed.
On 16 avr. 09, at 14:37, Robert D. wrote:
would use ruby19, irb19, etc.
OMG why did I not ask you, or err, reading ./configure --help a little
bit more carefully, before installing!!!
This avoids probably the kind of compatibility problems I ran into.
Juan, by all means, follow James’ approach if you cannot go with
JRuby.
R.
Maybe JRuby is the way to go except when I absolutely have to depend
on interfacing to C. I don’t have to worry about OS differences as
much. Also, the way jruby’s is distributed is great. I can download
it’s entire history and easily and update it easily. It’s trivial
to move between different versions, keep them in sync across
different systems, and not worry about screwing everything up.
With ruby1.9 it’s a different story. I admire the work that’s going
into ruby1.9. I’m just not sure it’s going to be so easy to manage.
I could try to deal with whatever versions happen to be in various
package managers. I could maintain a collection of tar balls. I
could maintain directories of different source trees. None of those
seem like very good solutions.