In Ruby 1.8.7, why does JSON syntax in IRB raise a Syntax, but not in a Rails 3.2.22.1 console? - ruby-on-rails-3

I'm responsible for maintaining a legacy Ruby on Rails application, and I'm currently testing it on Ruby v1.8.7 (2013-12-22 patchlevel 375). The app is using Rails v3.2.22.1 (a Rails version provided by Rails LTS). I am bumping into a weird syntax issue.
In a vanilla IRB console, the hash rocket syntax for a Hash works as expected, and the JSON syntax for raises a syntax error as expected. However, in a Rails console, the JSON syntax is working just fine, and I can't figure out why it's NOT raising a syntax error.
Any ideas what is going on in the code below?
# in Bash
$ ruby -v
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin18.2.0]
# in Rails console
Loading development environment (Rails 3.2.22.1)
irb(main):001:0> system "ruby -v"
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin18.2.0]
=> true
irb(main):002:0> {a: 1} # JSON syntax doesn't trigger SyntaxError
=> {:a=>1}
# loading vanilla IRB *()
irb(main):003:0> system "irb" # loading vanilla IRB
# in vanilla IRB (via Rails console, if that matters)
irb(main):001:0> system "ruby -v"
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin18.2.0]
=> true
irb(main):002:0> {a: 1} # expected syntax error
SyntaxError: compile error
(irb):2: odd number list for Hash
{a: 1}
^
(irb):2: syntax error, unexpected ':', expecting '}'
{a: 1}
^
from (irb):2

It turned out that the Ruby version set in the .ruby-version was 1.9.3-p551, and that caused Rails to load using Ruby 1.9.3-p551. That wasn't immediately obvious when I got the Ruby version from the system, but checking the Ruby version from within the app revealed the difference.
$ bundle exec rails console
irb(main):001:0> system "ruby -v"
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin18.2.0]
=> true
irb(main):002:0> RUBY_VERSION
=> "1.9.3"

Related

Rails upgrade from 5.0.7.1 to 5.1.7 problem

I try upgrading my rails app from 5.0.7.1 to 5.1.7. After rails app:update command rails -v return me 5.1.7, but command rails server return me next error:
.gem/ruby/2.6.8/gems/railties-5.1.7/lib/rails/commands/server/server_command.rb:101:in `module:Command': uninitialized constant Rails::Command::Base (NameError)
Did you mean? Base64
What can I do with it?

Gem install rails failed when used inside an rvm gemset name that includes characther colon ':'

I created an rvm gemset name that includes a colon, let's say project:marklar, then I do gem install rails inside that gemset. Everything goes well until it reaches json gem and throw this error:
Fetching: json-1.7.5.gem (100%)
Building native extensions. This could take a while...
/Users/username/.rvm/rubies/ruby-1.9.3p0/lib/ruby/site_ruby/1.9.1/rubygems/ext/builder.rb:48: warning: Insecure world writable dir /usr/local/mysql/bin in PATH, mode 040777
ERROR: Error installing rails:
ERROR: Failed to build gem native extension.
/Users/username/.rvm/rubies/ruby-1.9.3-p0/bin/ruby extconf.rb
creating Makefile
make
Makefile:158: *** target pattern contains no `%'. Stop.
I thought it was the ruby version that causes the problem, but when I changed into 1.9.2, it still throw the same error.
I used mac osx 10.8 mountain lion, surprisingly, when I removed the colon in the gemset name, let's say we changed it to marklar, everything goes well. Anyone noticed this behavior? Is this behavior expected or is it a bug in rvm, or in the json gem, or else?
I have compared Makefile defined in 1.9.3 and in 1.9.3#some:colon - there is no difference except the paths:
127,128c127,128
< RUBYLIBDIR = /home/mpapis/.rvm/gems/ruby-1.9.3-p194/gems/json-1.7.5/lib$(target_prefix)
< RUBYARCHDIR = /home/mpapis/.rvm/gems/ruby-1.9.3-p194/gems/json-1.7.5/lib$(target_prefix)
---
> RUBYLIBDIR = /home/mpapis/.rvm/gems/ruby-1.9.3-p194#some:colon/gems/json-1.7.5/lib$(target_prefix)
> RUBYARCHDIR = /home/mpapis/.rvm/gems/ruby-1.9.3-p194#some:colon/gems/json-1.7.5/lib$(target_prefix)
after further checking I found that space and colon are not allowed in file names: Escaping colons in filenames in a Makefile => http://www.mail-archive.com/bug-make#gnu.org/msg03318.html

Could not find generator mini_test:install

I expected these generators to be available:
$ rails g
Usage: rails generate GENERATOR [args] [options]
MiniTest:
mini_test:controller
mini_test:helper
mini_test:install
mini_test:mailer
mini_test:model
mini_test:scaffold
So I ran:
$ rails g mini_test:install
But got this error:
Could not find generator mini_test:install.
As for my environment, here is the relevant portion of my Gemfile:
group :test, :development do
gem 'minitest-rails'
end
And the resulting portions of my Gemfile.lock:
minitest (2.12.1)
minitest-rails (0.0.7)
minitest (~> 2.12)
rails (~> 3.1)
I am now in the process of debugging this. I would appreciate any tips. In any case, I will report back.
This is fixed in the 0.1 release of minitest-rails.
https://github.com/blowmage/minitest-rails
According to minitest-rails issue #41 - Generators are not found:
Try the prerelease gem, 0.1.0.alpha. Its a different approach and you'll need to update any existing tests.
I just confirmed that this worked for me:
$ rails g mini_test:install
create test
create test/minitest_helper.rb

Capistrano can't find a JavaScript runtime

I have a problem with Capistrano deploying to a server with RVM and gemsets
executing `deploy:assets:precompile'
* executing "cd /var/app/releases/20111229233555 && rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile"
*** [err ::] rake aborted!
*** [err ::] Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes.
*** [deploy:update_code] rolling back
failed: "rvm_path=$HOME/.rvm/ $HOME/.rvm/bin/rvm-shell '1.9.2#mygemset' -c 'cd /var/app/releases/20111229234715 && rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile'"
This is my Capfile
$:.unshift(File.expand_path('./lib', ENV['rvm_path']))
require 'rvm/capistrano'
set :rvm_bin_path, "$HOME/.rvm/bin"
set :rvm_ruby_string, '1.9.2#mygemset'
set :rvm_type, :user
load 'deploy/assets'
When I log in as the very same user which is used by Capistrano the failing command is executed without any problems.
It seems that Capistrano is using some other environment.
Here is my ~/.rvmrc file:
rvm_gemset_create_on_use_flag=1 rvm_trust_rvmrcs_flag=1
Is there a way how to check which ruby and gemset is used at the execution time?
node.js is and V8 are installed on the system, and all needed gems are in Gemfile:
here is my rvm info:
ruby:
interpreter: "ruby"
version: "1.9.2p290"
date: "2011-07-09"
platform: "x86_64-linux"
patchlevel: "2011-07-09 revision 32553"
full_version: "ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]"
homes:
gem: "/home/capistrano/.rvm/gems/ruby-1.9.2-p290#mygemset"
ruby: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290"
binaries:
ruby: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290/bin/ruby"
irb: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290/bin/irb"
gem: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290/bin/gem"
rake: "/home/capistrano/.rvm/gems/ruby-1.9.2-p290#mygemset/bin/rake"
setting up PATH in the deploy.rb solved this issue:
default_environment['PATH'] = "/usr/local/bin:/usr/bin:/bin:/opt/bin:$PATH"
it's a Gentoo distribution and the PATH var seems to be empty when using cap deploy, so I copied the content of server PATH and now it works
This issue went away for me when I installed nodejs (using apt-get) on my server. As I stated in this Stackoverflow answer, it's the most practical choice because you don't need to include any dependencies in your Gemfile.

thinking_shpinx, sphinx and MacOS X 10.6.7

After installing thinking_sphinx (http://freelancing-god.github.com/ts), and Sphinx (via brew - v.0.9.9-release (r2117) or via latest sources) and setting up ts in Rails3 (Ruby via RVM: ruby-1.9.2-p180 [ x86_64 ], rails 3.0.7) app like:
define_index do
indexes :name
end
and executing rake ts:start or rake ts:index, i permanently get:
ruby: invalid option -/ (-h will show valid options) (RuntimeError)
What the problem?