Running in to some parsing problems with ruby 1.9.2-p290 and rails 3.1.3.
My YAML file looks like this:
api_key: 12345
The other YAML files parse fine, like the database.yml and locale files. It's just this one.
Any ideas as to why?
there must be an error somwhere else, cause the line that you are showing is parsable by psych and syck engines:
YAML::ENGINE.yamler = 'psych'
YAML.load("api_key: 12345") # => {"api_key"=>12345}
YAML::ENGINE.yamler = 'syck'
YAML.load("api_key: 12345") # => {"api_key"=>12345}
Related
Ruby version: 2.2.5
Rails version: '~> 4.0.13'
Why I and my friend have received different result when trying to convert a string to YAML using YAML.dump method?
[1] pry(main)> YAML.dump("foo")
=> "--- foo\n"
[2] pry(main)> "foo".to_yaml
=> "--- foo\n"
While he has:
[1] pry(main)> YAML.dump("foo")
=> "--- foo\n...\n"
[2] pry(main)> "foo".to_yaml
=> "--- foo\n...\n"
With triple dots after new line (...)
UPDATED
I have confirmed that my rails is using Psych as YAML parser engine, in rails console:
2.2.5 :002 > YAML
=> Psych
2.2.5 :004 > Psych.dump("foo")
=> "--- foo\n"
2.2.5 :005 > YAML.dump("foo")
=> "--- foo\n"
2.2.5 :006 >
But still the result is somehow different. For additional informations, I don't have any syck gem installed and not required it in any files in my rails project.
It appears "You" might be using syck as a YAML processor while "He" is using psych. E.g.
require 'syck'
require 'psych'
Syck.dump("foo")
#=> "--- foo\n"
Psych.dump("foo")
#=> "--- foo\n...\n"
Both are valid YAML parser/emitters per se although Psych has been preferred since 1.9 and Syck really only exists as a gem for backwards compatibility and was completely removed from ruby standard lib as of 2.0.0
As for why "You" are somehow using Syck instead I cannot say without far more information than was provided in this post.
I met this issue this week and spent a great deal of time investigating the root cause. I have found that the difference of libyaml in the system will affect the dump.
For libyaml version 0.1.7, it will always include the ending characters like that, that's why you have the extra "...\n".
For libyaml version 0.2.1 and above, it supports implicit ending so those characters can be ignored
Since the default encoding is now utf-8 for Ruby 2.0, the rest-open-uri gem throws the following error on heroku:
/app/vendor/bundle/ruby/2.0.0/gems/bundler-1.5.2/lib/bundler/runtime.rb:76:in `require': /app/vendor/bundle/ruby/2.0.0/gems/rest-open-uri-1.0.0/lib/rest-open-uri.rb:413: invalid multibyte escape: /[\r\n\t !#-[]-~\x80-\xff]+|(\[\x00-\x7f])/ (SyntaxError)
I need to change the following line in rest-open-uri.rb. How can I access this file on heroku?
lib/ruby/gems/2.0.0/gems/rest-open-uri-1.0.0/lib/rest-open-uri.rb
# encoding: US-ASCII
rest-open-uri looks like a dead project. Do you want to get in the business of patching up 8 year old code to get your application to work?
It looks like rf-rest-open-uri is a more up-to-date fork of that project, have you tried it? I don't see any encoding instruction in that gem's rest-open-uri.rb source file.
Seeding the sqlite3 database with Fixtures did work with config1 but with config2 utf-8 support fails.
config1: Ubuntu 11.04, ruby 1.9.2p136, Rails 3.0.3, "development" environment
config2: OS X Lion, ruby 1.9.2p290, Rails 3.0.3, "development" environment
When having a yml file like
001:
id: 1
name: "\xC3\xBC"
I use it to populate the database with
Fixtures.create_fixtures(...)
in seed.rb
Afterwards the database shout have an entry with id 1 and name "ü". That would be correct.
That worked with config1. With config2 I alway have an entry with name "ü". utf-8 encoding seems to fail.
I already turned on UTF-8 everywhere in the rails project:
encoding: utf-8
in database.yml
# encoding: utf-8
in seeds.rb
Encoding.default_external = "UTF-8"
Encoding.default_internal = "UTF-8"
config.encoding = "utf-8"
in config/environments/development.rb
Is it possible that these two systems have different endianness?
From the SQLite3 release notes:
Support for UTF-8 and UTF-16
The new API for SQLite 3.0 contains routines that accept text as both
UTF-8 and UTF-16 in the native byte order of the host machine. Each
database file manages text as either UTF-8, UTF-16BE (big-endian), or
UTF-16LE (little-endian).
You can check here:
http://en.wikipedia.org/wiki/Endianness#Endianness_and_operating_systems_on_architectures
My Rails app is working from a mysql database, and when I switched from Rails 2.8, Ruby 1.8 and the mysql gem over to Rails 3.0.7, Ruby 1.9.2 and the mysql2 gem, all of a sudden my pages are rendering with smartquotes (curly quotes) and em-dashes, etc., all looking like gibberish.
I'm assuming this has something to do with UTF-8, but I don't know how to pinpoint it.
Here's what I do know:
(1) config/database.yml has the following:
development:
adapter: mysql2
encoding: utf8
(2) config/application.rb has the following:
config.encoding = "utf-8"
Don't know where to go from there.
Any suggestions?
You can narrow it down to the db vs the view by doing two things:
rails console # in your terminal in the project directory, then test that your ActiveRecord objects have the correct data.
ViewSource in your browser to see if the generated source is putting in the correct characters.
Later:
This is probably a duplicate of: mysql2 gem, Rails 3.0.3 and "incompatible character encodings" errors https://github.com/brianmario/mysql2/issues/124
And maybe even the monkeypatch here: http://www.rorra.com.ar/2010/07/30/rails-3-mysql-and-utf-8/
When I use Rails with YAML I change boot.rb with
require "yaml"
YAML::ENGINE.yamler = "syck"
It works fine with normal Ruby.
When I transfer the application from Ruby to JRuby, it doesn't work.
Where should I write these lines in JRuby?
Syck is a native gem. a gem that builds native extensions that is. jRuby and native extensions do not mix. Just don't use that syck snippet and your jRuby problem should go away.