I have an issue on Elastic Beanstalk deployment which is:
YAML syntax error occurred while parsing /var/app/ondeck/config/database.yml. Please note that YAML must be consistently indented using spaces. Tabs are not allowed. Error: (<unknown>): found character that cannot start any token while scanning for the next token at line 2 column 1 /var/app/ondeck/config/environment.rb:5:in `<top (required)>' /opt/rubies/ruby-2.4.2/bin/bundle:23:in `load' /opt/rubies/ruby-2.4.2/bin/bundle:23:in `<main>'
Caused by: Psych::SyntaxError: (<unknown>): found character that cannot start any token while scanning for the next token at line 2 column 1 /var/app/ondeck/config/environment.rb:5:in `<top (required)>' /opt/rubies/ruby-2.4.2/bin/bundle:23:in `load' /opt/rubies/ruby-2.4.2/bin/bundle:23:in `<main>' Tasks: TOP => environment (See full trace by running task with --trace).
As what I have read, this is because YAML forbids using tabs, instead it uses spaces.
The problem is that I manually checked every YAML file for tabs, and never found one. I think I missed something so my question is: is there any script that can go through my entire source code replacing tabs with 2 spaces in every YAML file?
It’s ruby after all: it’s easier and faster to write the script rather than ask questions on SO and google for it.
Dir['*/**/*.yml'].each do |f|
File.write(f, File.read(f).gsub(/\t/, ' '))
end
Related
As in "Alphabetize results of Dir.glob", I use sort to get file list in alphabetical order:
Dir.glob("#{options[:path]}/**/*.jpg", File::FNM_CASEFOLD).sort { |file|
dir, filename = file.match(/.+\/(.+)\/(.+)/).captures
# ---cut---
}
Without the sort it works good, but with it fails with error:
$ rake slides:import -- --user foo --path /bar/baz
(in /home/user/app_folder)
"baz/ - /bar/baz/DSC_4120.JPG - saved"
rake aborted!
ArgumentError: comparison of String with 0 failed
/home/footoo/footoo/lib/tasks/slides.rake:41:in `>'
/home/footoo/footoo/lib/tasks/slides.rake:41:in `sort'
/home/footoo/footoo/lib/tasks/slides.rake:41:in `block (2 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `eval'
/usr/local/rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => slides:import
Any idea what's wrong ?
Full code available on Github.
When sort is given a block it expects it to return -1,0 or 1 in order to know how to sort (a custom <=> function). You need to add each after sort to get back the default sort and the intended behavior.
Dir.glob("#{options[:path]}/**/*.jpg", File::FNM_CASEFOLD).sort.each{|file|
....
}
Read the documentation here: http://ruby-doc.org/core-2.2.0/Array.html#method-i-sort
After successfully testing my "alpha" Rails 3 app in my local dev environment, I pushed it up to Heroku (Cedar) for live testing. The push was successful, but the app crashes upon startup with the following errors:
: => Booting WEBrick
: => Ctrl-C to shutdown server
: /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.3/lib/active_support/dependencies.rb:251:in `require': /app/app/controllers/dives_controller.rb:50: invalid multibyte char (US-ASCII) (SyntaxError)
: /app/app/controllers/dives_controller.rb:50: syntax error, unexpected $end
: Exiting
I have checked for unexpected characters and missing end statements, but can not seem to find any. I am not using any multilingual characters (to my knowledge).
Here are a few of my files including: Gemfile, Gemfile.lock, database.yml, dives_controller.rb
https://gist.github.com/2632041
Could this possibly have something to do with using postgres and not specifiying it in my database.yml correctly?
If you look at lines 50 and 51 of dives_controller.rb, you will notice some weird white-space sort of characters appearing before (they are highlighted in the github output). I have a feeling those are the characters that are causing the problem.
They may have cropped up by pressing some random keys on your keyboard by mistake. Just remove them and replace them with a space.
I'm not exactly sure why this works, but I removed the following lines in my dives_controller.rb and the app now deploys correctly:
##user = User.where(:facebook_id => current_user.identifier)
##dive = #user.dives.create(params[:dive])
##dive = Dive.new(params[:dive])
The spaces highlighted in red in the Gist file are non-breaking spaces. A nightmare for developers.
You can ask your IDE or text editor to show them in a different character.
For example, set listchars=trail:◃,nbsp:• tells VIM to display • for non-breaking spaces and ◃ for trailing spaces.
My stack trace errors in ruby on rails look like below. I have happily used ctr-w gF to jump to the file and go to the line number following the file for a while.
However I started using RVM and gem_sets, and this puts a # symbol in the dir which apparently confuses Vim. How can I use my beloved ctr-w gF while this is the case?
/Users/x/.rvm/gems/ruby-1.8.7-p334#idance/gems/activesupport-3.0.7/lib/active_support/whiny_nil.rb:48:in `method_missing'
/Users/x/.rvm/gems/ruby-1.8.7-p334#idance/gems/arel-2.0.10/lib/arel/table.rb:103:in `[]'
/Users/x/.rvm/gems/ruby-1.8.7-p334#idance/gems/activerecord-3.0.7/lib/active_record/counter_cache.rb:34:in `reset_counters'
/Users/x/.rvm/gems/ruby-1.8.7-p334#idance/gems/activerecord-3.0.7/lib/active_record/counter_cache.rb:19:in `each'
/Users/x/.rvm/gems/ruby-1.8.7-p334#idance/gems/activerecord-3.0.7/lib/active_record/counter_cache.rb:19:in `reset_counters'
Include the # character in 'isfname'.
:set isf+=#-#
For more information:
:h 'isfname'
i use rails 2.3.9 with ruby 1.9.2 and when i trying to update my model with some russian letters i have error in unicorn log:
Error during failsafe response: incompatible character encodings: UTF-8 and ASCII-8BIT
Read error: #<NoMethodError: undefined method `[]' for nil:NilClass>
trace look like this:
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:521:in
process_client'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:594:in
block in worker_loop'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:592:in
each'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:592:in
worker_loop'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:482:in
block (2 levels) in
spawn_missing_workers'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:479:in
fork'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:479:in
block in spawn_missing_workers'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:475:in
each'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:475:in
spawn_missing_workers'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:489:in
maintain_worker_count'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:299:in
join'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn.rb:13:in
run'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/bin/unicorn_rails:208:in
<top (required)>'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/bin/unicorn_rails:19:in
load'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/bin/unicorn_rails:19:in
`'
so, i can't detirminate the problem, the only thing i know - what problem in russia text ( when i update model with english letters - all is ok. what i can do ? (
You should ensure that your editor saves files in UTF-8. ASCII afaik is the first part of any charset. That should be the reason you don't get any errors when you leave out the russian chars.
I answered this one here, with a script. Why are all strings ASCII-8BIT after I upgraded to Rails 3?
You need
# coding: UTF-8
at the top of your files, with ruby 1.9. If that doesn't help, it might be your external dependency, such as DB.
you can use gem "russian" (gem is based on l18n)
https://github.com/yaroslav/russian
in model (instead of russian letters):
Russian::translate(:some_word)
in config file (must be encoded in UTF-8):
ru:
some_word: 'это строка с русскими буквами (this is string with russian letters)'
Frequently I have run into a problem when installing gems that provides a problem like:
Does anyone know what this stems from? I've seen in it several different cases, yet still haven't learned what exactly is causing it.
$ sudo rake gems:install --trace
(in /u/app/releases/20100213003957)
** Invoke gems:install (first_time)
** Invoke gems:base (first_time)
** Execute gems:base
** Invoke environment (first_time)
** Execute environment
rake aborted!
cannot remove Object::ClassMethods
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_const'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `instance_eval'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `each'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/misc.rake:4
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/gems.rake:17
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
I believe I've found a practical non-intrusive method to get at the root of the problem. It works for me (Rails 2.3) :
As it happens Exception#blame_file! is invoked at some point in spite of the fact that it will fail and cause a new error, thus masking the original error.
So, open your FIRST initializer and add,
class Exception
def blame_file!( file )
puts "CULPRIT >> '#{file.to_s}' # #{self.to_s}"
end
end
You'll get both the incriminated file and the original error message. That should be enough to pinpoint your problem.
Don't forget to remove the Exception initializer snippet.
The cause of this error is a double exception. Usually something in your code is crashing, which raises an initial exception. Then Rails' custom require attempts to keep the namespace clean by removing partially defined constants, which is the purpose of the new_constants_in method. The problem is that new_constants_in is not properly handling some particular construction somewhere within the code, I suspect due to mishandling of module namespaces or something (because ClassMethods is probably inside some module other than Object). In any case, I have not traced the error back to a Rails component or anything else, because frankly it's not worth the effort.
The solution (short of proposing something a little less invasive to Rails core) is a quick hack to figure out what raised the original exception. All you need to do is go to where Dependencies.new_constants_in is called and comment it out (there are a few places where this could be). So for example:
def require(file, *extras) #:nodoc:
if Dependencies.load?
Dependencies.new_constants_in(Object) { super }
else
super
end
rescue Exception => exception # errors from required file
exception.blame_file! file
raise
end
Comment out the new_constants_in stuff:
def require(file, *extras) #:nodoc:
# if Dependencies.load?
# Dependencies.new_constants_in(Object) { super }
# else
super
# end
#rescue Exception => exception # errors from required file
# exception.blame_file! file
# raise
end
Then you'll see your error straight away.
I just came across this problem again. After some debugging I came to this conclusion: this weird error means that Rails has some troubles with requiring some particular library. The problem is that Rails doesn't tell us which library causes the problem. So, the first step you have to do is this:
Open this file (or the appropriate file in your installation):
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb
and edit the load_with_new_constant_marking method so it looks like this:
def load_with_new_constant_marking(file, *extras) #:nodoc:
if Dependencies.load?
Dependencies.new_constants_in(Object) { load_without_new_constant_marking(file, *extras) }
else
load_without_new_constant_marking(file, *extras)
end
rescue Exception => exception # errors from loading file
puts "FAILS HERE: " + file
exception.blame_file! file
raise
end
From now on, when running your application or a rake task, instead of just telling you that it "cannot remove Object::ClassMethods" Rails will tell you which file causes the problem (just look for the "FAILS HERE" statement). (Btw. I suppose this is what the exception.blame_file! method should be doing, but it obviously doesn't work that way.)
After you have located the file which causes the problem, you can dig into that particular chunk and use some exception blocks to get to the core of the problem.
Hope this helps.
I also started catching this bizarre error today -- traced it back to an out-of-date mysql gem .
I'd just switched from using the Mac MySQL package (the one that comes with a PrefPane) to a Homebrew-compiled version and the old /usr/local/mysql was lingering in my PATH
Deleting that directory (and other traces of the old MySQL) and then re-bundling my app solved it!
I ran into this issue, and tried each of the above solutions, but to no avail.
In my case, the problem was that I had accidentally included ActionView::Helpers::TextHelper and ActionView::Helpers::NumberHelper at the top of a file (thereby including them into the root Object class), this worked OK in Rails 3.0.0.rc, but raised the "cannot remove Object::ClassMethods" in Rails 3.0.1, and once raised, the app remained stuck until the server was restarted.
This started happening with me, but only after I included the delayed_job gem in my bundle. Like Eric above, I included ActionView::Helpers::TextHelper and ActionView::Helpers::NumberHelper at the top of a controller, but the funny thing is that I had no problems whatsoever until I started using delayed_job. I've no idea what's going on, I just removed the includes and the problem seems to have disappeared.