I am getting syntax error, unexpected tLABEL in below Ruby code. The error description is pointing to ':' after 'timeout'.
def self.run(*args, timeout: nil, environment: {})
# ...
end
I have no knowledge of Ruby. I have tried few things like replacing ':' with '=' or putting nil in {} but nothing seems to work.
My ruby version is 2.1.5.
IUQ-mini:~ IUQ$ rbenv versions
system
* 2.1.5 (set by /Users/IUQ/.ruby-version)
2.1.7
2.2.3
The particular code can be found here at line #38.
Few questions over SO points that this could happen due to misplaced braces but I did not see error - again my lack of Ruby knowledge!
Please help me to understand cause of this error and How can I resolve this?
Thanks
That won't work in ruby 1.9 (if in fact JRuby is limiting you to 1.9) as-is since the splat is expected to have a hash immediately following it if it's the first argument.
You can do something like this:
def self.run (environment = {}, timeout = nil, *args)
end
The only rub is you'll have to explicitly pass something (even nil) for timeout if you want to pass stuff in to be args[].
Calabash iOS and Android require ruby >= 2.0.
The latest released version of ruby is recommended.
JRuby of any version is not supported at this time.
Travis build
If you look at the info for that build, you'll see it failed because it was running on ruby 1.9.3.
I believe that you have ruby 2.0 installed. I don't think you are using it.
$ rbenv versions
system
1.8.7-p375
1.9.3-p484
2.0.0-p481
2.1.5
2.2.2
2.2.3
* 2.3.0 (set by /Users/moody/.rbenv/version) <== Active ruby in this dir
jruby-1.7.18
$ rbenv version # Active ruby in this directory
2.3.0
You never mentioned what version of run_loop you are using. You should update to the most recent stable release.
https://github.com/calabash/calabash-ios/wiki/Updating-your-run-loop-version
Related
getting this weird error
#<TypeError: wrong argument type nil (expected Symbol)>
in utf8_sanitizer
when doing next using binding.pry in rails 4.2.1 with ruby 2.2.0
otherwise running without any error.
I was getting this problem with some of my specs when I upgraded to Ruby 2.2 until I bumped byebug to 5.0.0 - not sure if it's the same since you didn't provide much description of your environment, but I hope this is helpful.
Upgrading ByeBug resolved the issue for me as well:
bundle update byebug
I have a legacy Rails application which I want to upgrade to recent Rails and Ruby versions.To start with I am trying to setup the application with Ruby 2.1.2
$ rails -v
Rails 2.3.18
$ ruby -v
ruby 2.1.2p95 (2014-05-08 revision 45877) [i686-linux]
When I tried to run the rake task rake db:schema:load RAILS_ENV=test I encountered following error
can not load translations from /activesupport-2.3.18/lib/active_support/locale/en.yml, the file type yml is not known
Searching through Google I found the following reference https://github.com/rails/rails/issues/10514 which mentioned that there is incompatibility between Rails 2.3 and Ruby 2+ versions.
Can anybody please help me applying a monkey-patch mentioned about in the reference link?
Thanks,
Jignesh
Finally resolved the error
can not load translations from /activesupport-2.3.18/lib/active_support/locale/en.yml, the file type yml is not known
by monkey-patching the Rails’s I18n::Backend::Base#load_file(filename) method.
The solution is as follows:
1.1 Created a file named ruby2.rb at /config/initializers
1.2 Added following contents to /config/initializers/ruby2.rb
if Rails::VERSION::MAJOR == 2 && RUBY_VERSION >= '2.0.0'
module I18n
module Backend
module Base
def load_file(filename)
type = File.extname(filename).tr('.', '').downcase
# As a fix added second argument as true to respond_to? method
raise UnknownFileType.new(type, filename) unless respond_to?(:"load_#{type}", true)
data = send(:"load_#{type}", filename) # TODO raise a meaningful exception if this does not yield a Hash
data.each { |locale, d| store_translations(locale, d) }
end
end
end
end
end
1.3 Finally ran
$ rake db:schema:load RAILS_ENV=test
and the schema was successfully loaded.
Most helpful references I could find and which helped me get to the solution:
https://github.com/rails/rails/issues/10514
https://www.lucascaton.com.br/2014/02/28/have-a-rails-2-app-you-can-run-it-on-the-newest-ruby/
I'm not sure if this belongs here or somewhere else (SuperUser?) but anyway:
I've got two Ruby scripts, one which requires Ruby 2.0 (A) and another which requires 1.8 (B). A needs to call B with a forked processes. A is something like this:
require "fileutils"
require "json"
...
`name_of_B`
B is an executable script with a shebang, starting like this:
#!/Users/user_name/.rvm/rubies/ruby-1.8.7-p374/bin/ruby
require 'rubygems'
require 'json'
...
I use RVM to manage my Ruby versions:
> rvm list
rvm rubies
ruby-1.8.7-p374 [ i686 ]
ruby-1.9.3-p448 [ x86_64 ]
=* ruby-2.0.0-p247 [ x86_64 ]
I run A with:
> ruby name_of_A
but end up with:
/Users/jacobevelyn/.rvm/gems/ruby-2.0.0-p247/gems/json-1.8.1/lib/json/ext/parser.bundle: [BUG] Segmentation fault
ruby 1.8.7 (2013-06-27 patchlevel 374) [i686-darwin12.5.0]
Any thoughts on what I can do? I don't know a whole lot about gems but it appears that B tries to look at gems installed under Ruby 2.0, rather than 1.8. (Yes, I've run gem install json under 1.8 already.) Obviously the scripts are more complicated than they appear here and absolutely cannot be ported or combined (this doesn't mean I don't want to, it means I can't for my use case), otherwise I would.
you need to change the shebang to:
#!/Users/user_name/.rvm/wrappers/ruby-1.8.7-p374/ruby
it will not only use that ruby but also its gems.
in case you use bundler (Gemfile) you might also need to wrap the command invocation in:
Bundler.with_clean_env do
...
end
which will reset loaded bundler environment
Call:
result = `\path\to\ruby_1_8 \path\to\ruby_1_8_script.rb`
This will use the correct ruby binary to execute the script that expects it. The result is saved into the var.
You can call which ruby to find the version of the ruby in your current directory. Go to your project / source dir and call it to see the version (presumably Ruby 2) that you're using for the main app. Then, go to your old project / repo (associated with the 1.8 script) and run it again. Hopefully that will show you the path to Ruby 1.8. If not, try it from root (/). Or use RVM to confidently switch to Ruby 1.8 and then call it there to get the path.
I've never used RVM much. If it is confused, and filters things through the wrong gem set, etc, then you may need instead to switch to rbenv. Also, you may need to use its own functions to display the true path to the Ruby 1.8 binary (i.e. maybe it messes with which?) Again, I don't RVM.
I just installed Mono 2.10 on my Mac and proceeded to run my Ruby Koans which I had previously finished to see if IronRuby got the same results as Mac's native Ruby 1.8.7. One of the tests midway through failed, and the issue seems to be this:
In Ruby 1.8.7, the following expression is false:
:sym.eql?("sym")
=> false
However, in IronRuby, it is true. The version of IronRuby I'm running is 1.1.2.0, which apparently is comparable to Ruby 1.9.2, so I downloaded that to check - it gets the same behaviour as Ruby 1.8.7. Is this an issue with IronRuby's implementation?
This is a bug according to the Ruby Spec. The semantics of #eql? are that it is true if == is true and if the objects are of the same class.
I had a exception when I switch to Ruby 1.8.7 on Snow Leopard
ArgumentError: wrong number of arguments (1 for 0)
/Library/Ruby/Gems/1.8/gems/activerecord-1.15.5/lib/active_record/connection_adapters/abstract/quoting.rb:27:in 'to_s'
/Library/Ruby/Gems/1.8/gems/activerecord-1.15.5/lib/active_record/connection_adapters/abstract/quoting.rb:27:in 'quote'
/Library/Ruby/Gems/1.8/gems/activerecord-1.15.5/lib/active_record/connection_adapters/mysql_adapter.rb:190:in 'quote'
/Library/Ruby/Gems/1.8/gems/activerecord-1.15.5/lib/active_record/base.rb:2042:in 'quote_value'
/Library/Ruby/Gems/1.8/gems/activerecord-1.15.5/lib/active_record/base.rb:2034:in 'attributes_with_quotes'
Application uses Rails 1.2.5: there is no chance to update rails in this app. Somebody have solution?
There will be a lot of compatibility issues with such an old version of rails and ruby 1.8.7. I would suggest using rvm to install multiple ruby versions / rails versions to test your app. I would also look into security patches as I am not sure if they are being backported to the 1.2.x branches.
I put this in a file inside config/initializers
class ::DateTime
alias_method :to_s, :to_formatted_s
end