‘jaap’ wrote a rake task to convert your Rails application from using Gettext translation into the new I18n support, which is really great!
WARNING: Before you run the new rake task rake gettext_to_i18n:transform, read “So How Do You Fix It?” below
OK, so you’ve followed along in the article and now you want to test out your new localization system. Problem is when you try to start the server up script/server you get this error message:
/Users/cblackburn/Source/ruby/bols/lib/active_support/memoizable.rb:71:in `path': can't modify frozen object (TypeError)…or something similar.
What happened? Since you have frozen Rails and the rake task does not exclude the frozen vendor/rails directory, it modified memoizable.rb in ActiveSupport causing this error.
So How Do You Fix It?
Do one of the following:
- Backup lib/active_support/memoizable.rb before you run the rake task, then restore it after.
- Restore lib/active_support/memoizable.rb using your SCM.
For this project in my case it was
svn revert lib/active_support/memoizable.rb
Head on over to François Marier’s blog ”Feeding the Cloud”, to learn how to setup a centralized git repository.
Come on guys, we should be past stupid upstream inconsistencies like this by now.
After reading all of the worthless posts regarding this error on Gentoo , I came up with the following solution:
sudo ln -s /usr/lib/libdbus-1.so.3 /usr/lib/libdbus-1.so.2
This error seems to rear its head on other platforms as well. I’m not sure if this solution will work on other platforms.
Just do it and be done.
UPDATE: Someone from the Gentoo team tried to leave a berating comment telling me to “read the _blank_ manual” and find that revdep_rebuild solves this problem. In response I can say that it indeed does NOT solve the problem. This is a really stupid bug in Gentoo and should be fixed. Come on guys! I love the product, but this is just retarded. It isn’t that difficult to fix the problem. Just do it once and for all. The amazing thing is that I still get emails and thanks for this resolution, even in Sabayon. I’m not sure who is responsible for this incompetency on the Gentoo team but there is simply no excuse.
revdep_rebuild!?!?! Only an amateur would think that nobody has tried that first.
It is likely that you have already used or have heard of AJAX. The ubiquitous example is Google Maps, which certainly wasn’t the first but is arguably the most quoted.
AJAX is a very useful technology but have you ever tried to use it across domains? For example, try to send an AJAX request from www.yoursite1.com to www.yoursite2.com. Does it work? Let me save you some time and tell you the answer is no. It won’t work by design. The Javascript specification considers cross-domain XMLHttpRequests to be a security risk, which it can be.
So, what if you have a legitimate business requirement to do cross-domain Javascript requests? The most important reason I can think of for this requirement is a third-party service, or web systems that are distributed across domains. There are many of these types of instances where cross-domain AJAX would be very valuable.
You could require the browser to download a Java applet, which would immediately alienate some browsers. You could use a Flash solution but again, many people simply won’t take the time to download the applet or plugin. More importantly for tracking services, sending Flash or Java applications to browsers on every request is simply not going to scale.
Enter Asynchronous Javascript Across Domains. How does it work?
- Javascript can dynamically generate or load more Javascript.
- Javascript can be loaded across domains.
Is the light going on yet?
So, we write some Javascript that will dynamically append a script tag