I'm trying to set the language mode in Rubinius, and it doesn't seem to work. I tried using the switch suggested by the Rubinius team in April 2012 in https://stackoverflow.com/a/10165964/38765
$ ruby --version
rubinius 2.0.0.n203 (1.9.3 4d75a146 2013-07-22 JI) [x86_64-apple-darwin11.4.2]
$ ruby -X18
irb(main):001:0> RUBY_VERSION
=> "1.9.3"
irb(main):002:0> exit
$ ruby -X20
irb(main):001:0> RUBY_VERSION
=> "1.9.3"
Is it possible to set language mode any more for Rubinius?
You have to enable the language modes when compiling rubinius. From the docs:
For example, to enable both 1.9 and 2.0 modes, with 1.9 the default,
use the follwing configure options:
./configure --enable-version=1.9,2.0 --default-version=1.9
Related
If I load a gem, let's say activerecord, in IRB require chooses the latest version of activerecord. Programmatically, what is influencing this decision to choose the latest gem version? Is require doing this, or is there something in the loaded IRB that forces requires to choose the latest version?
Here are my activerecord gems installed by bundler:
➜ ~ ls -al /Users/robskrob/.rvm/gems/ruby-2.4.1/gems/activere
activerecord-4.2.10/ activerecord-5.0.0.1/ activerecord-5.1.2/ activerecord-5.1.3/ activerecord-5.1.4/ activerecord-5.1.5/ activerecord-5.1.6/ activeresource-5.0.0/
And here is an example IRB session:
➜ ~ irb
2.4.1 :001 > require 'active_record'
=> true
2.4.1 :002 > Gem.loaded_specs['activerecord'].version
=> #<Gem::Version "5.1.6">
2.4.1 :003 >
If I load a gem, let's say activerecord, in IRB require chooses the latest version of activerecord.
Actually, it chooses the latest version that doesn't conflict with any already activated gem.
Programmatically, what is influencing this decision to choose the latest gem version? Is require doing this, or is there something in the loaded IRB that forces requires to choose the latest version?
This is requires job. More specifically, it is the job of the monkey-patched require from the RubyGems library, not the original require from the Ruby core library.
This is just simple separation of concerns: IRb is a REPL, not a package management system, it shouldn't know anything about packages.
I thought Ruby automatically converts to Bignum. I found confirmation here
However, it is not happening:
ruby 1.8.7 (358) [universal-darwin12.0]
>> 2 ** 62
=> 4611686018427387904
>> 2 ** 63
=> -9223372036854775808 #why minus - how about automatic Bignum conversion?
>> 2 ** 64
=> 0 #- how about automatic Bignum conversion?
Use a Newer Ruby Version
Ruby 1.8.7 is (in Internet terms) ancient. Use something more recent. For example:
[1] pry(main)> RUBY_VERSION
=> "2.0.0"
[2] pry(main)> 2 ** 63
=> 9223372036854775808
[3] pry(main)> 2 ** 64
=> 18446744073709551616
That is probably a bug in the old version of Ruby. Switch to a newer version, the problem is gone. Today is the release day for Ruby 2.0. Ruby 1.8 will be dead soon. On my Ruby 1.9.3, I just did 2**1000000 without any problem except that it goes on for a while, so I had to terminate it.
Most likely a bug specific to the build you're using. For example, when I do ruby -v I get:
ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-darwin12.2.1], MBARI 0x6770, Ruby Enterprise Edition 2011.03
...and in an irb session I get:
1.8.7 :006 > 2 ** 64
=> 18446744073709551616
1.8.7 :007 > (2 ** 64).class
=> Bignum
1.8.7 :008 > RUBY_VERSION
=> "1.8.7"
I also don't get this problem if I use newer versions. If you can post your output from ruby -v that would shine some light on the situation. For example Ruby REE vs. MRI vs. JRuby, etc.
Also, and this is just an opinion so take it for what it's worth, but I don't think Apple is very good about keeping their built-in version of Ruby updated, so just in case you're using the built-in version then consider moving to another build.
I'm getting a lot of syntax errors:
SyntaxError: /Users/davidtuite/dev/ruby/seenbefore_client/spec/lib/url_group_spec.rb:40: syntax error, unexpected ':'
records = stub(length: length)
yet the JRuby Blog says that "Compiler handles all 1.9 syntax now" since JRuby 1.6.0.rc2.
I'm using JRuby 1.6.5
rvm info
ruby:
interpreter: "jruby"
version: "1.6.5"
date: "2011-10-25"
platform: "darwin-x86_64-java"
patchlevel: "TM"
full_version: "jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]"
JRuby can be made 1.9.2-compatible by adding the --1.9 command line switch or by adding that switch to the JRUBY_OPTS environment variable:
$ export JRUBY_OPTS='--1.9'
$ bin/irb
irb(main):001:0> RUBY_VERSION
=> "1.9.2"
irb(main):002:0> {asd:3}
=> {:asd=>3}
Don't know how you can tell your RVM that, though. By the way, on Windows the batch syntax is set JRUBY_OPTS=--1.9.
So I am developing a Sinatra for both windows and linux. The problem is I'm using Thin instead of Webrick and eventmachine for windows only works with a pre-release version while linux uses the latest stable. in the gemfile you of course cannot include the same gem with different versions like so:
gem "eventmachine", "~> 1.0.0.beta.4.1", :group => :development_win
gem "eventmachine", group => :development_linux
gem "thin
I was wondering if there was a way to work around this, maybe using one gemfile for windows and one gemfile for linux, what would the command be to load one or the other.
Alternatively is there a way to perhaps in git manage just the gemfile for two different platforms, perhaps through a branch for just the file (don't know if that's possible from what I've read of git branches).
You can do it like that:
# Windows
gem "eventmachine", "~> 1.0.0.beta.4.1", :platform => [:mswin, :mingw]
# C Ruby (MRI) or Rubinius, but NOT Windows
gem "eventmachine", :platform => :ruby
Full list of available platforms:
ruby C Ruby (MRI) or Rubinius, but NOT Windows
ruby_18 ruby AND version 1.8
ruby_19 ruby AND version 1.9
ruby_20 ruby AND version 2.0
mri Same as ruby, but not Rubinius
mri_18 mri AND version 1.8
mri_19 mri AND version 1.9
mri_20 mri AND version 2.0
rbx Same as ruby, but only Rubinius (not MRI)
jruby JRuby
mswin Windows
mingw Windows 'mingw32' platform (aka RubyInstaller)
mingw_18 mingw AND version 1.8
mingw_19 mingw AND version 1.9
mingw_20 mingw AND version 2.0
You can find more information in Gemfile(5) man page here (see 'Platforms' section).
Another approach is to use RUBY_PLATFORM constant:
if RUBY_PLATFORM =~ /win32/
gem "eventmachine", "~> 1.0.0.beta.4.1"
else
gem "eventmachine"
end
I haven't seen full list of available values for RUBY_PLATFORM but you can run
ruby -e 'puts RUBY_PLATFORM'
on both your platforms and see the difference.
You can use the --gemfile option to use different gemfiles for different platforms. See the documentation here
http://gembundler.com/man/bundle-config.1.html
You need multiple versions (all with the same name) of a gem. Therefore, currently with Bundler, you need multiple, simultaneous Bundler dependency snapshot 'lock' files. This is possible, if your developers make use of Bundler's gemfile configuration setting. They might do this either:
By making use of environment variable BUNDLE_GEMFILE (on the command line or in .bash_profile); or
(Probably less desirably) in .bundle/config (globally, in their home directories).
Thus, safely, Bundler can create (and presumably automatically later use, given the same configuration settings) e.g. Gemfile-linux.lock and Gemfile-windows.lock.
Although this basic approach seems workable, it's not very DRY. However, this improves if, e.g., both Gemfile-linux and Gemfile-windows automatically incorporate whatever Gemfile statements they share in common: i.e., if they include the statement:
::Kernel.eval(File.open('Gemfile-common','r'){|f| f.read},::Kernel.binding)
The following code snippet works fine in 1.8.7 on Mac OS X, but not in 1.8.6 on Ubuntu. Why? Is there a workaround?
Works in 1.8.7:
$ ruby --version
ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]
ltredgate15:eegl leem$ irb
>> 6.times.map {'foo'}
=> ["foo", "foo", "foo", "foo", "foo", "foo"]
>>
But not in 1.8.6:
# ruby --version
ruby 1.8.6 (2008-08-11 patchlevel 287) [i686-linux]
Ruby Enterprise Edition 20090610
# irb
irb(main):001:0> 6.times.map {'foo'}
LocalJumpError: no block given
from (irb):1:in `times'
from (irb):1
irb(main):002:0>
Why is there a difference? What's the workaround for 1.8.6?
In 1.8.7+ iterator methods like times return an enumerator if they are called without a block. In 1.8.6 you have to do
require 'enumerator'
6.enum_for(:times).map {...}
Or for this specific use case you could simply do (0...6).map {...}
In Ruby 1.9, the library was changed so functions that did iteration would return an Enumerator object if they were called without a block. A whole host of other language features were also changed, and it was widely known that compatibility would be broken between Ruby 1.8.x and Ruby 1.9 in the interests of improving the language as a whole. Most people didn't find this too distressing.
The Ruby development team decided that Ruby 1.8.7 should be a transition release adding some of the library features that Ruby 1.9 introduced. They took a lot of criticism for the decision, and many enterprise Ruby users remained (and many still remain) running Rails on Ruby 1.8.6, because they feel the changes introduced 1.8.7 are just too large, and too risky. But nevertheless, 1.8.7 remains, and having iteration functions return Enumerators is one of the features that was incorporated.
It is this migration feature that you're seeing in 1.8.7, which is not present in 1.8.6.
sepp2k's answer gives a good workaround. There's not much for me to add on that count.
Because 1.8.6 #times yields on the given block, while 1.8.7 returns an Enumerator object you can keep around and implements Enumerable.
Ruby 1.8.7 introduces many changes. If you want to use them in Ruby 1.8.6, simply
require 'backports'
That's it. This gives you many methods of 1.9.1 and the upcoming 1.9.2 as well, although it's possible to require 'backports/1.8.7' for just the changes of 1.8.7, or even just the backports you need, e.g. require 'backports/1.8.7/integer/times'