Running rails application server fails - YAML parser? [duplicate] - ruby-on-rails

After updating the gems I've got this:
/home/megas/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in `parse': couldn't parse YAML at line 182 column 9 (Psych::SyntaxError)
from /home/megas/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
from /home/megas/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:119:in `parse'
from /home/megas/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:106:in `load'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/RedCloth-4.2.3/lib/redcloth/formatters/latex.rb:6:in `<module:LATEX>'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/RedCloth-4.2.3/lib/redcloth/formatters/latex.rb:3:in `<top (required)>'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/RedCloth-4.2.3/lib/redcloth.rb:21:in `require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/RedCloth-4.2.3/lib/redcloth.rb:21:in `<top (required)>'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/RedCloth-4.2.3/lib/case_sensitive_require/RedCloth.rb:6:in `require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/RedCloth-4.2.3/lib/case_sensitive_require/RedCloth.rb:6:in `<top (required)>'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler/runtime.rb:68:in `require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler/runtime.rb:68:in `block (2 levels) in require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler/runtime.rb:66:in `each'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler/runtime.rb:66:in `block in require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler/runtime.rb:55:in `each'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler/runtime.rb:55:in `require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/bundler-1.0.10/lib/bundler.rb:120:in `require'
from /home/megas/Work/railscasts/config/application.rb:10:in `<top (required)>'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands.rb:28:in `require'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands.rb:28:in `block in <top (required)>'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands.rb:27:in `tap'
from /home/megas/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands.rb:27:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'
ruby-1.9.2-p136
rails 3.0.3
Tried to reinstall gem RedCloth, didn't help, system wants to use only 4.2.3 version
Any idea how to fix it? Thanks

You have invalid YAML code somewhere. I mean invalid for Psych (the new ruby YAML parser).
If you cannot (or don't want to) fix your YAML code, try to load the old YAML parser (syck), adding this at the beginning of config/boot.rb
require 'yaml'
YAML::ENGINE.yamler = 'syck'
It's just a 'quick and dirty' fix, I know

My regular Rails 3 App also had this problem, because I was using a localized yaml File for Date/Times.
As you can see in this commit https://github.com/rails/rails/commit/dc94d81
this can be easy "fixed" by placing the array in seperate lines.
- order: [ :year, :month, :day ]
18 + order:
19 + - :year
20 + - :month
21 + - :day

A slight tweak on Paul Raupach's answer which, when run from a directory, finds all *.yml files recursively in all sub-directories and tests the file. I ran it from my Rails root dir.
require 'yaml'
d = Dir["./**/*.yml"]
d.each do |file|
begin
puts "checking : #{file}"
f = YAML.load_file(file)
rescue StandardError
puts "failed to read #{file}: #{$!}"
end
end

The root cause was described on many places and I will summarize it again.
There are two default yaml parser Psych is the new one, the one you should be using. Syck is the old one, its not maintained and dying, its currently used as fall back for when there is no libyaml present (non-linux systems usually).
The important thing is you have some invalid yaml somewhere. It is most probably in your translation files (I had unquoted strings strating with %). Just try loading all your yml files with YAML.load_file on the production box and you will see which one is the broken one.

I had this problem because i had used a tab instead of spaces

It's best to fix your YAML files
Here is how using irb so you don't need the rails console which is probably not working:
require 'yaml'
YAML::ENGINE.yamler = 'psych'
YAML.load_file('config/locales/xxx.en.yml')
you'll get a nice output telling you where the issue is:
Psych::SyntaxError: couldn't parse YAML at line 25 column 17
from /home/xxx/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse'
from /home/xxx/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
from /home/xxx/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:119:in `parse'
from /home/xxx/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:106:in `load'
from /home/xxx/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:205:in `load_file'
from (irb):10
from /home/xxx/.rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `<main>'

Absolutely fix your yaml code don't just 'mask' the real problem by forcing YAMl to use 'syck'. I had this same problem and found malformed yml statements in my localization files. If you just force using the older parser then you will not get the benefits of all the work on the new parser elsewhere in your project.

The problem with the original question was in RedCloth. I was experiencing the same issue and simply updating to the most recent version of the RedCloth gem (Currently 4.2.7) fixed the issue.
The above advice from Honza and FlyboyArt is sound and you should fix any custom YAML you have, but with RedCloth being as popular as it is, most users finding this question who also use RedCloth should make sure their GemFile has this line added:
gem 'RedCloth', ">= 4.2.7"

For others reading this, I got this error after making a typo in my database configuration - /config/database.yml

It's a bundler 1.0.10 issue: details here
Try just to downdate bundler

What fixed it in my cause was indeed malformed YAML translation file in:
config/locales/bg.yml
Corrected the YAML mistake and it was all fine. :-)

For those pursuing this issue I have just found that my database.yml was triggering this error because it had no space between the password: keyword and the password. An almost invisible error, and with a database.yml that had worked without errors on an earlier version of rails.

I got this error from trying to connect to a remote db with the password 'p#ssword' and figured out that psych doesn't like the '#' symbol. Changed the DB password and problem solved.

I had this problem. My problem was I had an extra tab in my database.yml file.

I came across this as I was using the r18n library in a Sinatra app I'm building, and in my translation file I had the following:
day: !!pl
0: 0 days
1: 1 day
n: %1 days
which used to work just fine in an older project under Ruby 1.8.7, but which was failing under Ruby 1.9.3.
An answer by #SB gave me the clue I needed to work out my problem. The newer YAML was balking at the %1. Some quick digging and an experiment with irb and I now know that the newer version of the YAML parser requires you to put quotes around strings that start with %1, so I just changed my translation to be
day: !!pl
0: 0 days
1: 1 day
n: "%1 days"
and voila - nasty error message vanished.

For my case, it is not a Bundle issue: (Ruby 1.9 is assumed)
Ruby, by default, uses 'psych' (newer and maintained yaml library linking to the C library: libyaml) if libyaml is present
Otherwise, Ruby uses 'syck' (old and not maintained)
YAML::ENGINE.yamler= 'syck' will thus forces Ruby to use 'syck' on a machine where 'psych' is also installed
More info here: require "yaml" doesn't use psych as default

I manage to fix this problem by installing gem psych inside group :development and :test.
gem 'psych'

I had the same issue with ruby 1.9.2-p180 , going to 1.9.2-p290 solved this for me

Though the answer given by #Vicvega may or may not work (Didn't test it) it goes against Rails and Ruby common principle "Convention over configuration" and should be treated with care (and even more in collaborative work),,, even though the "configuration" in this case is not great
so my vote goes (If i could vote) for those who proposed to eliminate the syntax errors in the YAML files.
now... to solve the error, for me it was kind of a newby error, I didn't have the locale file which I had defined to be the default in Config/application.rb in my Config/locales directory
happy coding

Need to check .yml files for error, I have found problem in my database.yml

I had a similar issue with a malformed YAML translation file. It used a variable before defining it. The following was wrong:
...
messages:
...
<<: *errors_messages
...
messages: &errors_messages
...
It had to be changed to:
...
messages: &errors_messages
...
messages:
...
<<: *errors_messages
...
Then it started working again.

In my case there were 2 issues.
As mentioned by #stwienert, the array representation was an issue.
One more thing was, if a String started with a %{var} I received a Parse exception. I had to change the strings accordingly to avoid beginning with %{var}
For example if the string was
%{user_name} welcome to %{application_name} -- This threw an error
To fix it I had to change it to
Hi, %{user_name} welcome to %{application_name}
Hope this helps someone.
Regards,
Shardul.

Well, just in case this helps...
What I did:
- select all and copy from https://github.com/svenfuchs/rails-i18n/tree/master/rails/locale/es.yml into a new es.yml with notepad++
- tried to watch this new file with netBeans IDE text editor, I got a warning about safe load with utf8 (cannot recall the exact text). Hence did not open it with this text editor.
- switched the local thru configuration/application.rb i18n
- when I loaded a irb page I got "couldn't parse YAML at line 0 column 0" referring to Psych. - Went to IRB and loaded the file with syck it was ok; switched to psych and got same error.
How I solved it:
- went back to copy the contents from https://github.com/svenfuchs/rails-i18n/tree/master/rails/locale/es.yml but this time I pasted it in a newly created file with netBeans editor.
- restarted webRick.
- problem solved.
Best Regards,
Victor

Remove unused databases from database.rb.
If you use MySQL and there is no PostgreSQL then delete PG database code from databases.yml.

Pshych parse is suck to the core. I am not sure if this is elegant solution but i manage to fix this problem by uninstalling it.
gem uninstall psych

I had a really, really strange problem because I had spaces after. E.g.:
title: "NASA"
Did not work, but
title:"NASA"
Did.

If you're like me and facing a project (inherited) with hundreds of fixtures a few lines of Ruby can save you hours:
require 'yaml'
d = Dir.new('test/fixtures/')
d.each do |file|
begin
f = YAML.load_file('test/fixtures/' + file)
rescue StandardError
puts "failed to read test/fixtures/#{file}: #{$!}"
end
end
Just put it in your Rails root and run it, trash it when you're done.

For other people looking at this I found the issue in rerun.txt which was being called by config/cucumber.yml in a Rails app. rerun.txt was configured to store the most recent cucumber failing test and I had somehow entered weird characters for a cucumber test in the console.
That was hard to find. Wish I had seen Glenn Rempe's answer a while back.

One of the possible causes is mapping values are not allowed in this context at line ...
Here is an incorrect YAML example (user: should not contain any value actually, because it contains children items some_key and some_other_key)
customer: Customer
user: User
some_key: value
some_other_key: value 2
It's not a trivial task to find such issue especially if you have a huge YAML file.
I've created a pretty simple regexp to detect such things.
I checked it in RubyMine
^(\s+)['"\w]+:\s?['"\w]+.*\n\1\s\s
Be careful! It doesn't work correct with special chars like å ø æ etc.
Let me know in comments if it worked for you :)

Related

undefined method `set_params' for OpenSSL::SSL::SSLContext

I've created a gem called kmdata that has an executable. When running bundle exec kmdata decot.7 from within my gem's folder everything works fine. After releasing the gem to rubygems I ran gem install kmdata (in a new window). I then tried to run kmdata decot.7 and I get the following
/Users/kyledecot/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/net/http.rb:891:in `connect': undefined method `set_params' for #<OpenSSL::SSL::SSLContext:0x007fff31d59d18> (NoMethodError)
from /Users/kyledecot/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/net/http.rb:862:in `do_start'
from /Users/kyledecot/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/net/http.rb:851:in `start'
from /Users/kyledecot/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/net/http.rb:1367:in `request'
from /Users/kyledecot/.rvm/gems/ruby-2.0.0-p247/gems/kmdata-0.0.3/lib/kmdata.rb:24:in `get'
from /Users/kyledecot/.rvm/gems/ruby-2.0.0-p247/gems/kmdata-0.0.3/bin/kmdata:5:in `<top (required)>'
from /Users/kyledecot/.rvm/gems/ruby-2.0.0-p247/bin/kmdata:23:in `load'
from /Users/kyledecot/.rvm/gems/ruby-2.0.0-p247/bin/kmdata:23:in `<main>'
The line in lib/kmdata.rb is
response = http.request(Net::HTTP::Get.new(path))
Update #1
This only appears to be an issue when using 2.0. If I run the same command in 1.9.3 then everything works as expected.
You likely need to include this line (e.g., at the beginning of your file):
require 'openssl'
I had this error on 2.0, and adding this line fixed it. Maybe your 1.9.3 has some configuration/gem that implicitly requires that?
Just out of the blue, but have you configured Net::HTTP to use an SSL connection?
Using Net::HTTP.get for an https url
Here's another person having the same problem...no mention that it's a solution, but try it out: https://www.ruby-forum.com/topic/4417738
This looks like an error in Net::HTTP...are you using the most recent version of the gem?
If I were you, I would focus on:
undefined method `set_params' for #<OpenSSL::SSL::SSLContext:0x007fff31d59d18> (NoMethodError)
I think you could have your gems organized in such a way that there's either something not being included, or you have two classes or methods with the same name, and the wrong one is now being chosen.
I've had something like this happen a couple of times.
Simply put, it's probably going to end up being a scope thing - a require / include, or a duplicate method.
If I'm right, there's not much we can do to help - without access to your computer.
I hope you find it. I would recommend doing some grepping/searching through files for method names, class names etc. if you haven't already.
Edit:
looking back, it seems like you're just dealing with stock code.
If that's the case, try uninstalling all versions of ruby, and then re-installing 2.0.0. You'd be surprised - I've had 1.9.3 do something like this when they are both installed.

Rails 3.1.0.rc4 + Postgres - cannot read from or write to database after reboot

I've just started to write an application using the latest version of Rails and PostgreSQL. I created the database, added required gem, configured database.yml file and started with two models - User (this one used Devise for authentication) and Group. I created an additional controller for start page (simple one - only to display list of links). Everything seemed fine, I was able to add test data to the database - until I came back this morning and wanted to continue work.
As long as I stayed on the home page, everything looked just like yesterday. But when I tried to access group list, I got the following error:
Routing Error
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.map
There was no additional informations on the page, so I looked into Webrick console and saw the following:
ActionController::RoutingError (You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.map):
app/controllers/groups_controller.rb:1:in `<top (required)>'
The first line of my controller is, as usual:
class GroupsController < ApplicationController
I looked at the other actions, and the result was the same: unexpected nil object. Same issue occured while trying to perform any action on User.
I suspected it's a database problem (because it didn't affect the controller that wasn't using database at all), so I went to rails console to see if I could add entries manually. I couldn't.
ruby-1.9.2-p180 > group = Group.new
(some SQL)
NoMethodError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.map
from /home/lite/.rvm/gems/ruby-1.9.2-p180/gems/activerecord-3.1.0.rc4/lib/active_record/persistence.rb:320:in `attributes_from_column_definition'
from /home/lite/.rvm/gems/ruby-1.9.2-p180/gems/activerecord-3.1.0.rc4/lib/active_record/locking/optimistic.rb:69:in `attributes_from_column_definition'
from /home/lite/.rvm/gems/ruby-1.9.2-p180/gems/activerecord-3.1.0.rc4/lib/active_record/base.rb:1525:in `initialize'
from (irb):1:in `new'
from (irb):1
from /home/lite/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.1.0.rc4/lib/rails/commands/console.rb:45:in `start'
from /home/lite/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.1.0.rc4/lib/rails/commands/console.rb:8:in `start'
from /home/lite/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.1.0.rc4/lib/rails/commands.rb:40:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'
I looked into the most top file (persistence.rb) and searched for line 320.
319: def attributes_from_column_definition
320: Hash[self.class.columns.map do |column|
321: [column.name, column.default]
322: end]
323: end
This definition gave me a little idea what might be happening, so I ran one more command in the console (Group.inspect) and I got error on the following line:
attr_list = columns.map { |c| "#{c.name}: #{c.type}" } * ', '
It seems like I'm not able to access the columns of my table, but I have no idea why. I'm logged in as the same user, on the same machine, using the same operating system and kernel. Out of curiosity, I created another application and it didn't work after the reboot either.
I've spent now four hours looking for answer, but I couldn't find anything related. What might be causing this problem and how to fix it?
I have found the guilty one: small gem called 'automatic_foreign_key' I used to automatically detect foreign keys. When I rollback the changes it made, removed it and altered the table manually, I had my application working again.
Thank you all for help!
Maybe Group is a reserved word in this version of postgresql or rails. rails-3.1.0-rc4 is the most fresh version of rails. Generate another dead simply model to check it.

ImageScience breaks on update to Rails 3

I had a working (and working well) ImageScience install, that did some simple resizing to various dimensions of images, and then copying them to different directories. All very simple. This small and simple routine was in a rake task. Upon update to Rails 3, this rake task will still work (it does some AR inserts and audio encoding as well), but the image_science require fails with a message like this,
"require on /home//.ruby_inline/Inline_ImageScience_cdab.so failed"
I've ruled out a duff ImageScience install, as I can go into IRB and do some simple calls to ImageScience and make thumbnails. The remainder of the rake task works as well as it did before if I comment out any mention of requiring 'image_science' or the ImageScience routine.
the output from rake on failure is this,
/var/lib/gems/1.8/gems/RubyInline-3.8.6/lib/inline.rb:513:in `load'
/var/lib/gems/1.8/gems/RubyInline-3.8.6/lib/inline.rb:829:in `inline'
/var/lib/gems/1.8/gems/image_science-1.2.1/lib/image_science.rb:90
...
<active_support complaints >
...
/home/<user>/RailsApps/marlow/lib/tasks/flac_import.rake:2
...
<rails complaints>
...
/home/<user>/RailsApps/marlow/Rakefile:7
...
<standard complaints to end>
the Rakefile in the rails app root is a stock and standard Rails 3 Rakefile, like this,
# Add your own tasks in files placed in lib/tasks ending in .rake,
# for example lib/tasks/capistrano.rake, and they will automatically be available to Rake.
require File.expand_path('../config/application', __FILE__)
require 'rake'
Marlow::Application.load_tasks
the last line is line 7.
I'm kind of stumped as to what's breaking it, and Google doesn't seem to shed anything. Does anyone know why RubyInline is complaining? Or why this once working Rake task is suddenly unhappy how ImageScience is being called? OS is Ubuntu 10.10, but it was all working prior to the Rails 3 upgrade.
Thanks in advance
This does seem to be the problem, but there is a simpler fix I found from perusing the comments at carlhuda issues 431
I had the same problem and it worked for me. Simply change the require method to be Kernel.require.
After that there's no need to pepper your code with require image_science statements.
There is a fix, but you'll need to jump through few hoops.
First delay image_science load:
gem 'image_science', :require => false
Then monkey patch ruby-inline (which image_science relies on). Place this code in config/initializers/ruby_inline_hack.rb:
class Inline::C
def load
require "#{so_name}"
#below is the original version which breaks
#require "#{so_name}" or raise LoadError, "require on #{so_name} failed"
end
end
Then require 'image_science' wherever you're using it. And voila.
One note on aremave's answer:
It looks like the original code has a bug! It's not using short-cut-evaluation!
class Inline::C
def load
require "#{so_name}" || raise LoadError, "require on #{so_name} failed"
end
end
Notice the || , which will stop the evaluation of the logical expression if the first part is true.
If there is an 'or' in the same place, the second part of the expression will always be evaluated,
hence the error you're seeing...
as seen on bundler issue tracker, it worked for me.
Point your gem file to https://github.com/asynchrony/image_science We rebuilt image science without ruby inline.

What does "Anonymous modules have no name to be referenced by" really mean?

I'm upgrading my Rails app to work with Ruby 1.9 and I keep encountering errors like this:
Anonymous modules have no name to be referenced by
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:585:in `to_constant_name'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:391:in `qualified_name_for'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:104:in `rescue in const_missing'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:94:in `const_missing'
/home/foo/app/config/environment.rb:66:in `block in <top (required)>'
etc.
Google finds all kinds of hits for this, but each of them pertains to a specific fix for one specific gem or app. None of them explain what the message really means.
What is an "anonymous module"?
Where is this error message coming from? (The Ruby interpreter itself?)
What is different about Ruby 1.9 that causes this? (Rails 2.3.8 with Ruby 1.8.7 does not encounter this.)
What is the general/proper way to fix this error?
Line 66 of environment.rb is the configuration for super_exception_notifier (old version, 2.0.8):
ExceptionNotifier.configure_exception_notifier do |config|
config[:sender_address] = %("Foo" <foo#foo.com>)
config[:exception_recipients] = %w(foo#foo.com)
config[:skip_local_notification] = false
end
From what I can tell, ExceptionNotifier is undefined, and ActiveSupport is trying to magically load it, but fails and then fails again trying to print a nice error message.
An anonymous module is a module that is declared like so:
Fred = Module.new do
def meth1
"hello"
end
def meth2
"bye"
end
end
instead of by using the regular Module mod_name <block> syntax. Since they have no module name, you can't retrieve the module name. to_constant_name is attempting to call desc.name.blank? where desc is an anonymous module (with no name).
This error is coming from the ActiveSupport module, which may indicate a bug in the active_support gem or may indicate that some other piece of code is using ActiveSupport incorrectly. The error message alone doesn't give enough information to identify the culprit (to me at least, someone with more rails experience might be able to provide more insight).
Without knowing the offending code it's also hard to say exactly why this error is popping up with 1.9, or what needs to be done to fix it. Considering that there are a lot of un- and under-maintained gems out there that have not been updated for 1.9 yet, I would suspect that ActiveSupport is not the source of the problem. Upgrade all of your gems that have 1.9-compatible versions, and then try disabling your other gems one at a time (if you can) and see if you still get the error.
If you provide a list of the other gems that you are using, someone else who may have encountered the error before may be able to provide some details.
This may happen if you try to exploit ActiveRecord's internal class and module contexts in the wrong way. I had this error yesterday while working on a gem which extends deep inner workings of ActiveRecord. I finally managed to get around this problem by redesigning my code which exploits the inner contexts. It would be interesting to see the surrounding lines of environment.rb:66 for further analysis.
This may happen when the class name doesn't match the filename, in
my case it was a file named application.rb contaning the ApplicationController
class. Renaming the file to application_controller.rb solved the problem.
When I got this error, it was due to a misspelling while defining a class. If you are getting this error, it may be worth examining your module and class definitions for typos.

Undefined method '>>' for class 'Date' in Rails 3 on Ruby 1.8.7/1.9.2

I'm running a Rails 3.0.0 application on Ruby 1.8.7-p174. Everything was going swimmingly until I tried to run some tests:
/Users/avand/.rvm/gems/ruby-1.8.7-p174/gems/activesupport-3.0.0/lib/active_support/core_ext/date/calculations.rb:9: undefined method `>>' for class `Date' (NameError)
from /Users/avand/.rvm/gems/ruby-1.8.7-p174/gems/activesupport-3.0.0/lib/active_support/ruby/shim.rb:12:in `require'
from /Users/avand/.rvm/gems/ruby-1.8.7-p174/gems/activesupport-3.0.0/lib/active_support/ruby/shim.rb:12
from /Users/avand/.rvm/gems/ruby-1.8.7-p174/gems/actionpack-3.0.0/lib/abstract_controller.rb:6:in `require'
from /Users/avand/.rvm/gems/ruby-1.8.7-p174/gems/actionpack-3.0.0/lib/abstract_controller.rb:6
I took a look into that Calculations class, noting that undef was being called with :>>. But Ruby 1.8.7 Dates don't have a >> method. I figured I'd wrap it with a condition: if respond_to?(:>>). Things broke further along this time:
/Users/avand/.rvm/gems/ruby-1.9.2-rc2/gems/activesupport-3.0.0/lib/active_support/core_ext/date/calculations.rb:91:in `alias_method': undefined method `+' for class `Date' (NameError)
from /Users/avand/.rvm/gems/ruby-1.9.2-rc2/gems/activesupport-3.0.0/lib/active_support/core_ext/date/calculations.rb:91:in `<class:Date>'
from /Users/avand/.rvm/gems/ruby-1.9.2-rc2/gems/activesupport-3.0.0/lib/active_support/core_ext/date/calculations.rb:7:in `<top (required)>'
from /Users/avand/.rvm/gems/ruby-1.9.2-rc2/gems/activesupport-3.0.0/lib/active_support/ruby/shim.rb:12:in `require'
from /Users/avand/.rvm/gems/ruby-1.9.2-rc2/gems/activesupport-3.0.0/lib/active_support/ruby/shim.rb:12:in `<top (required)>'
from /Users/avand/.rvm/gems/ruby-1.9.2-rc2/gems/actionpack-3.0.0/lib/abstract_controller.rb:6:in `require'
The second stack trace is Ruby 1.9.2. I'm getting the same error with Ruby 1.9.2 without my respond_to? check as Ruby 1.8.7 with it.
I commented out my Date extensions in lib. This only occurs in the test environment.
Thoughts?
So this may not be the most helpful answer but it's all I've been able to determine so far.
The file in question: activesupport-3.0.0/lib/active_support/core_ext/date/calculations.rb removes the definitions of :>> as you saw. If the file is require twice, the second loading of that file will fail due to the method no longer being defined on the Date class.
So why is this file being required twice? That I'm really not sure of. I've seen that the protection against this can be buggy (if you'd call it a bug, it may just be a limitation) when you specify the file with a full path once and then another time you depend on the LOAD_PATH having the correct folder in it to find you file that way.
I'd look through your code and see what is requiring either rails/all or activesupprt/railstie and hopefully you'll see two separate places that look slightly different. Also see if you're mucking with the LOAD_PATH anywhere between the two places.

Resources