Hi,

I am having the following problem with Psych and BigDecimal.

ruby-head :006 > Psych.dump(10.67)
=> "--- 10.67\n...\n"
ruby-head :007 > Psych.dump(BigDecimal("10.67"))
=> "--- !ruby/object:BigDecimal {}\n"
ruby-head :008 > Psych.dump(BigDecimal("10.67").to_s)
=> "--- !binary |-\n MC4xMDY3RTI=\n"
ruby-head :009 > d = Psych.dump(BigDecimal("10.67"))
=> "--- !ruby/object:BigDecimal {}\n"
ruby-head :010 > Psych.load(d)
TypeError: BigDecimal can't be coerced into BigDecimal
from /Users/suaconta/.rvm/gems/ruby-head/gems/hirb-0.5.0/lib/hirb/view.rb:200:in inspect' from /Users/suaconta/.rvm/gems/ruby-head/gems/hirb-0.5.0/lib/hirb/view.rb:200:inview_or_page_output'
from /Users/suaconta/.rvm/gems/ruby-head/gems/hirb-0.5.0/lib/hirb/view.rb:186:in output_value' from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:160:inblock (2 levels) in eval_input'
from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:273:in signal_status' from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:156:inblock in eval_input'
from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb/ruby-lex.rb:243:in block (2 levels) in each_top_level_statement' from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb/ruby-lex.rb:229:inloop'
from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in block in each_top_level_statement' from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb/ruby-lex.rb:228:incatch'
from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in each_top_level_statement' from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:155:ineval_input'
from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:70:in block in start' from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:69:incatch'
from /Users/suaconta/.rvm/rubies/ruby-head/lib/ruby/1.9.1/irb.rb:69:in start' from /Users/suaconta/.rvm/rubies/ruby-head/bin/irb:16:in

The same problem occurs with Rails 3.0.7

I've already tried to monkey patch Psych but was unsuccessfully.

Im using Mac Os X and Ruby 1.9.4

I think the "init_with" hook-method should be called "decode_with" so that it is symmetric with the "encode_with" method.

In addition, putting psych in the hook-method names would be helpful:

• encode_with() => encode_with_psych()
• init_with() => decode_with_psych()

This ought to reduce method-name collisions as well. Cheers.

Merging in a non-existing aliased key simply raises TypeError: can't convert nil into Hash.

Psych.load "foo:
  <<: *bar"

Given that this message is so generic, it makes debugging pretty tough. Something along the lines of Psych::UnkownAlias would be a huge time-saver.

As already documented at this issue on rubygems:
rubygems/rubygems.org#358

$ gem install git-branch-delete-orphans
Fetching: git-branch-delete-orphans-0.0.2.gem (100%)
/Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse': couldn't parse YAML at line 22 column 13 (Psych::SyntaxError)
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:119:in `parse'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:106:in `load'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:488:in `from_yaml'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_input.rb:190:in `load_gemspec'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_input.rb:55:in `block in initialize'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_reader.rb:64:in `block in each'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_reader.rb:55:in `loop'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_reader.rb:55:in `each'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_input.rb:35:in `initialize'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_input.rb:20:in `new'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_input.rb:20:in `open'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:44:in `open'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/format.rb:62:in `from_io'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/format.rb:46:in `block in from_file_by_path'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/format.rb:45:in `open'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/format.rb:45:in `from_file_by_path'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:119:in `format'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:129:in `spec'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:386:in `ensure_required_ruby_version_met'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:156:in `install'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:297:in `block in install'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each_with_index'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:in `block in execute'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:in `process_args'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in `run'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:in `run'
    from /Users/loberhub/.rvm/rubies/ruby-1.9.2-p290/bin/gem:25:in `<main>'

http://stackoverflow.com/questions/9759302/documentation-for-psych-to-yaml-options

Are the functions in emitter.c the only options supported? Can documentation for these options be moved into the rb for dump so they're accessible? And then get any reasonably documented version described on ruby-doc.org?

Was this not ported yet?

Note: this probably needs to be fixed in collectiveidea/delayed_job#199 rather than psych, but I thought it best to include it here in case other people come looking, or if a similar issue affects other libraries.

Loading psych before delayed_job causes the latter to crash.

$ ruby -rdelayed_job -e"puts :hello"
hello

$ ruby -rpsych -rdelayed_job -e"puts :hello"
/Users/paul/.rvm/gems/ruby-1.9.2-p136/gems/delayed_job-2.1.3/lib/delayed/yaml_ext.rb:30:in `remove_method': method `to_yaml' not defined in Class (NameError)
    from /Users/paul/.rvm/gems/ruby-1.9.2-p136/gems/delayed_job-2.1.3/lib/delayed/yaml_ext.rb:30:in `<class:Class>'
    from /Users/paul/.rvm/gems/ruby-1.9.2-p136/gems/delayed_job-2.1.3/lib/delayed/yaml_ext.rb:28:in `<top (required)>'
    from <internal:lib/rubygems/custom_require>:29:in `require'
    from <internal:lib/rubygems/custom_require>:29:in `require'
    from /Users/paul/.rvm/gems/ruby-1.9.2-p136/gems/delayed_job-2.1.3/lib/delayed_job.rb:6:in `<top (required)>'
    from <internal:lib/rubygems/custom_require>:33:in `require'
    from <internal:lib/rubygems/custom_require>:33:in `rescue in require'
    from <internal:lib/rubygems/custom_require>:29:in `require'

This is because of delayed_job-2.1.3/lib/delayed/yaml_ext.rb (abridged):

require 'yaml'

class Module
  def to_yaml( opts = {} )
    YAML::quick_emit( nil, opts ) { |out|
      out.scalar(taguri, self.name, :plain)
    }
  end
end

class Class
  remove_method :to_yaml # use Module's to_yaml
end

Please refer to http://stackoverflow.com/questions/4980877/rails-error-couldnt-parse-yaml/5107098#5107098

I wonder if it's a known issue.

File: x.yaml

:a: [:a, :b, :c]

I can parse it easily in 1.9.1:

ruby-1.9.1-p378 :003 > require 'yaml'
 => true 
ruby-1.9.1-p378 :004 > YAML.load_file('x.yaml')
 => {:a=>[:a, :b, :c]} 
ruby-1.9.1-p378 :005 > YAML::VERSION
 => "0.60" 

But it doesn't work in 1.9.2:

kronos:engine:$ rvm use 1.9.2
Using /Users/kronos/.rvm/gems/ruby-1.9.2-p136
kronos:engine:$ irb
ruby-1.9.2-p136 :001 > require 'psych'
 => true 
ruby-1.9.2-p136 :002 > Psych.load_file('x.yaml')
Psych::SyntaxError: couldn't parse YAML at line 0 column 6
    from /Users/kronos/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in `parse'
    from /Users/kronos/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
    from /Users/kronos/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:119:in `parse'
    from /Users/kronos/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:106:in `load'
    from /Users/kronos/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:205:in `load_file'
    from (irb):2
    from /Users/kronos/.rvm/rubies/ruby-1.9.2-p136/bin/irb:16:in `'

This was discovered while I was playing around with roodi:

This YAML fragment parses fine under both Syck and Psych:

ClassNameCheck:                  
  pattern: !ruby/regexp /^[A-Z][a-zA-Z0-9]*$/

However, if you turn this into a single line object

ClassNameCheck:                  { pattern: !ruby/regexp /^[A-Z][a-zA-Z0-9]*$/ }

Psych blows up on it, although Syck handles it fine.

Psych::SyntaxError: couldn't parse YAML at line 4 column 60
from /Users/andrew/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse'
from /Users/andrew/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
from /Users/andrew/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:119:in `parse'
from /Users/andrew/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:106:in `load'
from /Users/andrew/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:205:in `load_file'
from (irb):8
from /Users/andrew/.rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `<main>'

I got following error.

% rake gem
(in /home/tomo/devel/ruby/psych)
mkdir -p pkg
rake aborted!
Don't know how to build task 'bench.rb'

(See full trace by running task with --trace)

How can I avoid this?
Sorry if it is not psych's issue.

Is there an option to be able to pars {k:"v"} much like {k: "v"}?

Please make binary gems available as RubyInstaller users installing or updating (with or without the DevKit installed) will almost certainly run into install failures due to

https://github.com/tenderlove/psych/blob/master/ext/psych/extconf.rb#L10

and not having libyaml artifacts available for a manual --with-libyaml-dir=... fixup.

Thanks.

UPDATE to clarify, RubyInstaller users can install Psych if they have the DevKit installed and the have they libyaml dev artifacts installed by running something similar to the following. However, I get runtime 'missing yaml.dll' error messages I'm tracking down (my C:\devlibs\libyaml\lib includes both libyaml.a and libyaml.dll.a)

C:\Users\Jon>gem install psych -- --with-libyaml-include=C:/devlibs/libyaml/include --with-lib-yaml-lib=C:/devlibs/libyaml/lib
Fetching: psych-1.2.2.gem (100%)
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
Successfully installed psych-1.2.2
1 gem installed

Bottom line, manual gem install is too tweaky and a static linked binary gem would be great.

Hi all,

I faced a problem serializing ActiveRecord Relations in hashes:

>> {a: User.where(initials: 'TT')}.to_yaml
=> FAILS

As a workaround I convert the relation to an array

>> {a: User.where(initials: 'TT').all}.to_yaml
=> GREAT SUCCESS 

Happens with syck as well

>> YAML::ENGINE.yamler = 'syck'
=> "syck"

>> {a: User.where(initials: 'TT')}.to_yaml
>> FAILS

Not sure how to handle it best? Maybe forcing #to_a in ActiveRecord::Relation#to_yaml just like #as_json does?

The full console output with stacktraces is here: https://gist.github.com/acc75942606bd8dd6063

Edit: Now I think I should have submitted the issue to rails, not psych...

Is there any way to detect if a file and/or string is YAML?

Maybe something like:

YAML.document?(io_or_text)

would be a good addition, if not.

In my Rails 3.2.2 app

Psych.load('--- foo')  

works fine in my local (production) console. But in on Heroku (cedar stack, ruby 1.9.2) I get this error:

irb(main):001:0> Psych.load('--- foo') 
LoadError: no such file to load -- --- foo
    from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.2/lib/active_support/dependencies.rb:245:in `load'
    from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.2/lib/active_support/dependencies.rb:245:in `block in load'
    from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.2/lib/active_support/dependencies.rb:236:in `load_dependency'
    from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.2/lib/active_support/dependencies.rb:245:in `load'
    from (irb):1
    from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.2/lib/rails/commands/console.rb:47:in `start'
    from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.2/lib/rails/commands/console.rb:8:in `start'
    from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.2/lib/rails/commands.rb:41:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

Anyway to access information about the source of YAML when defining a type? I have a case where I want to know if the source was a file and what the file path is.

YAML::add_domain_type("foo.com,2011", "foo") do |type, value|
    from_file = ?  # 'foo.yaml'
    Foo.new(value, :file=>from_file)
end

YAML.load(File.new('foo.yaml'))

Hi. There seems to be an error regarding reading objects that have cyclic references. They are dumped as expected (required yaml anchors are in place) but on load they are omitted (resulting in nil). Syck on 1.8.7 is handling this case correctly.

Psych from master branch, using ruby-1.9.2-head ruby 1.9.2p274 (2011-06-06 revision 31932) [x86_64-darwin10.7.0] although it's also failing on stable 1.9.2

Here's a failing test case:

diff --git a/test/psych/test_object.rb b/test/psych/test_object.rb
index 9890d50..10665c7 100644
--- a/test/psych/test_object.rb
+++ b/test/psych/test_object.rb
@@ -11,6 +11,14 @@ module Psych
     end
   end

+  class Foo
+    attr_accessor :parent
+
+    def initialize(parent)
+      @parent = parent
+    end
+  end
+
   class TestObject < TestCase
     def test_dump_with_tag
       tag = Tagged.new
@@ -23,5 +31,12 @@ module Psych
       assert_equal tag.baz, tag2.baz
       assert_instance_of(Tagged, tag2)
     end
+    
+    def test_cyclic_references
+      tag = Tagged.new
+      foo = Foo.new(tag)
+      tag.baz = foo
+      assert_cycle(tag)
+    end
   end
 end

Hi,
There is a difference of behaviour in the following test script if you load psych. With regular yaml each element has a unique object_id, with psych the object_id of the template an the object into which the template is injected is the same:

=begin
  require 'psych'
rescue LoadError
=end

require 'yaml'

object_ids = []

yaml = YAML::load(<<-eoyml

---
DEFAULTS: &DEFAULTS
  user: ed
one:
  <<: *DEFAULTS
  name: fido 
  user: ed

two:
  name: rover 
  user: bob 
eoyml
)

yaml_value = [yaml]

yaml_value.each do |item|
  item.each do |data|
    data.each do |inner|
      object_ids << inner.object_id
    end
  end
end

b = Hash.new(0)

# iterate over the array, counting duplicate entries
object_ids.each do |v|
  b[v] += 1
end

b.each do |k, v|
  #will raise this error if you require psych
  raise "multiple entries found" if v > 1
end

This is causing a problem with some rails fixtures on a project I'm upgrading.

We've got some code in rspec-mocks that uses Psych if available, and otherwise falls back to Syck. I built a release candidate gem (rspec-mocks-2.6.0.rc1) using Ruby 1.9.2 compiled with Psych, and released it. When I tried to install it, I got the error listed below.

I then built the gem (2.6.0.rc2) in a Ruby 1.8.7 environment and the release was successful (in as much as you can install it - we have yet to see if people like it).

I don't know if this is a Psych issue or if there is something else I can be doing, but I'd love to avoid avoiding building in a 1.9.2+Psych env.

ERROR:  While executing gem ... (NameError)
    uninitialized constant Psych::Syck
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:198:in `load'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:198:in `_load'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:133:in `load'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:133:in `fetch_spec'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in `block in fetch_with_errors'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:93:in `map'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:93:in `fetch_with_errors'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:108:in `find_gems_with_sources'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:228:in `find_spec_by_name_and_version'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:260:in `install'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:64:in `run'
    /Users/david/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `'

I just upgraded to Psych 1.2.1 and ran into a problem with serializing times in my Rails app. Essentially serialize/deserialize roundtrips were losing their timezone information.

A look at my rails log shows some weirdness:

INSERT INTO etl_logs (job_name, last_run_date, last_run_time, last_run, rows_processed, job_errors, rows_imported, run_time, stats, created_at, updated_at, additional_data, hostname, pid) VALUES('Incremental import of TT tickets', '2011-10-03', '2011-10-03 12:19:58', '2011-10-03 12:19:58', NULL, 0, NULL, 0, NULL, '2011-10-03 12:22:17', '2011-10-03 12:22:17', '---\n:timestamp: 0.040103\n:svn_version: $HeadURL$\n:svn_rev: $Rev$\n:version_txt: $HeadURL$\n:start_job_time: 0.013328075408935547\n:start_job_calls: 1\n:updating_running_jobs_time: 0.0029239654541015625\n:updating_running_jobs_calls: 1\n:get_job_datetime_time: 9.489059448242188e-05\n:get_job_datetime_calls: 1\n:etl_errors: 1\n:tt_incr_skipped_increments: 1\n:soft_aborts: 1\n:parse_time: 0.031224966049194336\n:parse_calls: 1\n:max_ticket_timestamp: 2011-10-03 18:43:58.667334000 %:z\n:tt_import_next_params:\n :last_timestamp: 2011-10-03 18:43:58.667334000 %:z\n :next_row: 1\n :max_rows: 2000\n :job_type: :incremental\n:start_job_average_time: 0.013328075408935547\n:updating_running_jobs_average_time: 0.0029239654541015625\n:get_job_datetime_average_time: 9.489059448242188e-05\n:parse_average_time: 0.031224966049194336\n', 'eds-big-laptop.lan', 82462)

Note the :last_timestamp field about 3/4 of the way through; it ends "%:z" rather than the UTC offset..

A quick grep and the culprit is found in lib/psych/visitors/yaml_tree.rb line 311. There is a spare colon hanging around in the format string of the strftime.

I'll have a patch with tests shortly.

Psych does not seem to be encoding the class if the object it is serialising is a subclass of Hash.

To whit:

class PreferenceHash; end
ruby-1.9.2-p180 :006 > YAML.dump PreferenceHash.new
"--- !ruby/object:PreferenceHash {}\n"

ruby-1.9.2-p180 :009 > class PreferenceHash2 < Hash; end
ruby-1.9.2-p180 :011 > YAML.dump PreferenceHash2.new
"--- {}\n"

This behaviour is unexpected to me.

If you have a YAML file that is being updated from both Syck and Psych, string values matching /(\d\d:)+\d\d/ can be corrupted. There is a sample script in this gist. Such a value might be a bare time or a duration in the form HH:MM:SS.

Syck interprets bare values with this pattern as "base 60" numbers according to the YAML 1.1 definition of a float. Psych (or libyaml) does not interpret values this way (as seems correct according to YAML 1.2 and my own personal preferences).

Syck will quote strings that match this pattern; Psych does not. This means that a value matching this pattern in a YAML file that is updated by both Syck and Psych will eventually be corrupted into an integer. You can see that in the gist — the file is created using Syck, then updated using Psych, then updated again using Syck. At the third load-dump cycle, the first two duration values have turned into integers.

This is really an unfortunate behavior on the part of Syck, but it would be nice if Psych would quote the strings to avoid it.

Implement add_builtin_type for rails support.

I am facing following issue while parsing json data containing timestamp. Psych is able to parse timestamp when it is not wrapped with braces. With braces it parse date correctly. However, timestamp with braces (json hash) breaks.

1.9.2 (main):0 > YAML::ENGINE.yamler = "psych"
=> "psych"
1.9.2 (main):0 > YAML.load "CREATE_DT: 2011-09-27 04:38:25.0"
=> {"CREATE_DT"=>2011-09-27 10:08:25 +0530}
1.9.2 (main):0 > YAML.load "{CREATE_DT: 2011-09-27}"
=> {"CREATE_DT"=>#<Date: 2011-09-27 (4911663/2,0,2299161)>}
1.9.2 (main):0 > YAML.load "{CREATE_DT: 2011-09-27 04:38:25.0}"
Psych::SyntaxError: couldn't parse YAML at line 1 column 25
from /Volumes/DATA/Bhavin/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/psych.rb:148:in `parse'

This is a feature request. I like symbols. An argument could be made about object duplication and so on, but I just like them because they are easier to type. It would be nice to have an option to parse hash keys as symbols.

For example:

irb(main):001:0> Psych.load("---\n ananas: sweet\n bananas: yellow")
=> {"ananas"=>"sweet", "bananas"=>"yellow"}
irb(main):002:0> Psych.load("---\n ananas: sweet\n bananas: yellow", :symbolize_keys => true)
=> {:ananas=>"sweet", :bananas=>"yellow"}

With a recent RubyInstaller build of ruby_1_9_3 I get the following error from a custom app. I've tried tweaking psych.rb but the only workaround I've found is to chcp 65001 my cmd.exe as chcp 1252 and the default chcp 437 fails.

C:\Users\Jon>lackee map
C:/ruby193/lib/ruby/1.9.1/psych.rb:206:in `parse': YAML file must be UTF-8, UTF-16LE, or UTF-16BE, not IBM437 (ArgumentError)
from C:/ruby193/lib/ruby/1.9.1/psych.rb:206:in `parse_stream'
from C:/ruby193/lib/ruby/1.9.1/psych.rb:289:in `load_stream'
from C:/ruby193/lib/ruby/1.9.1/psych/deprecated.rb:28:in `load_documents'
from C:/ruby193/lib/ruby/gems/1.9.1/gems/logging-1.7.2/lib/logging/config/yaml_configurator.rb:53:in `initialize'
from C:/ruby193/lib/ruby/gems/1.9.1/gems/logging-1.7.2/lib/logging/config/yaml_configurator.rb:37:in `new'
from C:/ruby193/lib/ruby/gems/1.9.1/gems/logging-1.7.2/lib/logging/config/yaml_configurator.rb:37:in `load'

I'm working to extract a simple test case for you, but the relevant part of my code simply uses

https://github.com/TwP/logging/blob/master/lib/logging/config/yaml_configurator.rb#L24

like Logging::Config::YamlConfigurator.load(CONFIG_FILE.realpath.to_s)

My ruby environment:

C:\Users\Jon>ripl
>> RUBY_DESCRIPTION
=> "ruby 1.9.3p174 (2012-04-03 revision 35222) [i386-mingw32]"
>> require 'psych'; Psych::VERSION
=> "1.3.1"
>> Gem::VERSION
=> "1.8.21"

I suspect 9eb1264 and am working on more info. Hopefully this is enough to get started.

Is there are reason I am overlooking at why this doesn't parse?

---
param: how_high [Integer] height of the jump
returns: [String] String of tartar.
example: |
  Example.new.jump  #=> "tartar"
...

Note that the same project with 1.1.pre.8 works fine

2011-09-21T09:48:05+00:00 heroku[web.1]: State changed from crashed to created
2011-09-21T09:48:05+00:00 heroku[web.1]: State changed from created to starting
2011-09-21T09:48:07+00:00 heroku[web.1]: Starting process with command bundle exec rails server -p 7438
2011-09-21T09:48:08+00:00 app[web.1]: Unfortunately, a fatal error has occurred. Please report this error to the Bundler issue tracker at https://github.com/carlhuda/bundler/issues so that we can fix it. Thanks!
2011-09-21T09:48:08+00:00 app[web.1]: /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler/settings.rb:5:in initialize': uninitialized constant Bundler::Settings::YAML (NameError) 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:188:innew'
2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:188:in settings' 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:282:inconfigure_gem_home_and_path'
2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:85:in configure' 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:139:indefinition'
2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:129:in load' 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler.rb:113:insetup'
2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler/cli.rb:402:in exec' 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler/vendor/thor/task.rb:22:inrun'
2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler/vendor/thor/invocation.rb:118:in invoke_task' 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler/vendor/thor.rb:263:indispatch'
2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/lib/bundler/vendor/thor/base.rb:386:in start' 2011-09-21T09:48:08+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.pre.9/bin/bundle:13:in<top (required)>'
2011-09-21T09:48:08+00:00 app[web.1]: from vendor/bundle/ruby/1.9.1/bin/bundle:19:in load' 2011-09-21T09:48:08+00:00 app[web.1]: from vendor/bundle/ruby/1.9.1/bin/bundle:19:in

Is this expected behavior?

$ which ruby                  
/Users/kunzmann/.rvm/rubies/ruby-1.9.2-p290/bin/ruby

pysch_error_handling.rb

require 'psych'

begin
  Psych::load("hello:\n  - invalid\nyml")
rescue Psych::SyntaxError
  puts 'can haz error handling?'
end

begin
  Psych::load("hello:\n  - invalid\nyml")
rescue
  puts 'can haz error handling?'
end

produces:

$ ruby psych_error_handling.rb
can haz error handling?
/Users/kunzmann/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse': couldn't parse YAML at line 4 column 0 (Psych::SyntaxError)
    from /Users/kunzmann/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:148:in `parse_stream'
    from /Users/kunzmann/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:119:in `parse'
    from /Users/kunzmann/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:106:in `load'
    from psych_error_handling.rb:10:in `<main>'

I also tried with the following Gemfile:

gem 'psych', '~> 1.2.0'

with this addition to the top of pysch_error_handling.rb:

require 'bundler/setup'

which produces:

$ ruby psych_error_handling.rb
/Users/kunzmann/.rvm/gems/ruby-1.9.2-p290/gems/psych-1.2.0/lib/psych.rb:93: warning: already initialized constant VERSION
/Users/kunzmann/.rvm/gems/ruby-1.9.2-p290/gems/psych-1.2.0/lib/psych.rb:96: warning: already initialized constant LIBYAML_VERSION
can haz error handling?
/Users/kunzmann/.rvm/gems/ruby-1.9.2-p290/gems/psych-1.2.0/lib/psych.rb:154:in `parse': couldn't parse YAML at line 4 column 0 (Psych::SyntaxError)
    from /Users/kunzmann/.rvm/gems/ruby-1.9.2-p290/gems/psych-1.2.0/lib/psych.rb:154:in `parse_stream'
    from /Users/kunzmann/.rvm/gems/ruby-1.9.2-p290/gems/psych-1.2.0/lib/psych.rb:125:in `parse'
    from /Users/kunzmann/.rvm/gems/ruby-1.9.2-p290/gems/psych-1.2.0/lib/psych.rb:112:in `load'
    from psych_error_handling.rb:11:in `<main>'

I guess this is because Psych::SyntaxError doesn't inherit from StandardError. Perhaps that is by design, but it caught me by surprise - so I thought I'd ask.

Psych doesn't seem to support merge keys ( http://yaml.org/type/merge.html ) with alias/anchor the same way that syck does. I'm not sure if this is intentional or not, but its a pretty useful behavior so I'm filing a bug. Basically, while psych does allow one to use a merge key to pull a aliased mapping into another mapping, it does not allow one to add other items to that mapping. Very frequently I have a map that is mostly in common amongst a number of keys, with a subkey that differs, and this bug makes it impossible to achieve this behavior with psych.

For the yaml snippet below:

foo: &foo
  hello: world
bar:
  << : *foo
  baz: boo

syck produces: {"foo"=>{"hello"=>"world"}, "bar"=>{"hello"=>"world", "baz"=>"boo"}}

psych produces: {"foo"=>{"hello"=>"world"}, "bar"=>{"hello"=>"world"}}

Note that in the yaml 1.1 spec ( http://yaml.org/spec/1.1/#id902561 ) it says "Note that an alias node must not specify any properties or content, as these were already specified at the first occurrence of the node.", however I think this should only apply when doing something like "bar: *foo". When using a merge key, you are creating a new node (which you don't add to), but merging it into a different mapping node - which you should be able to add to.

The Readme documentation looks very sparse! Are there any blog posts, videos, slides or anything similar out there demonstrating use of this gem? Or is the only option to look at the tests? Thanks ;)

Hi,

We've had reports that Psych can't parse the YML inside RefineryCMS even though syck can. Here is the link to the issue on our repository with heaps of conversation around it:

https://github.com/resolve/refinerycms/issues/#issue/457

The simple solution to this issue is to put this in our config/boot.rb:

require 'yaml'
YAML::ENGINE.yamler= 'syck'

AKA disable Psych, no more problem. Weird?

Thanks!
Phil

I found a situation where the engine will crash hard on a specific kind of input. The result looks something like this:

ruby(48546,0x7fff7003cca0) malloc: *** error for object 0x101929e50: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Since Rails uses Psych as the default serializer now, any data with irregular characters could trigger this kind of problem. Most parts of Ruby will throw an "invalid UTF-8" exception instead of exploding like this.

I've created a minimal test-case that blows up on Ruby 1.9.2-p290 on OS X (64-bit):

#!/usr/bin/env ruby
# encoding: BINARY

# MacRoman encoded text "naïve"
naive = "na\x95ve"

require 'psych'

Psych.dump([ 'test', naive ])

Using rdebug I was able to extract a stack trace showing how this trip-up occurred:

/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:21:in `scalar'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:21:in `visit_Psych_Nodes_Scalar'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/visitor.rb:6:in `accept'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:26:in `block in visit_Psych_Nodes_Sequence'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:26:in `each'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:26:in `visit_Psych_Nodes_Sequence'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/visitor.rb:8:in `accept'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:16:in `block in visit_Psych_Nodes_Document'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:16:in `each'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:16:in `visit_Psych_Nodes_Document'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/visitor.rb:10:in `accept'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `block in visit_Psych_Nodes_Stream'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `each'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `visit_Psych_Nodes_Stream'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/visitors/visitor.rb:11:in `accept'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych/nodes/node.rb:36:in `to_yaml'
/opt/local/rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/psych.rb:166:in `dump'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/base.rb:1720:in `block in arel_attributes_values'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/base.rb:1713:in `each'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/base.rb:1713:in `arel_attributes_values'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/persistence.rb:265:in `create'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/timestamp.rb:47:in `create'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/callbacks.rb:277:in `block in create'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.0.7/lib/active_support/callbacks.rb:414:in `_run_create_callbacks'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/callbacks.rb:277:in `create'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/persistence.rb:246:in `create_or_update'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/callbacks.rb:273:in `block in create_or_update'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.0.7/lib/active_support/callbacks.rb:419:in `_run_save_callbacks'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/callbacks.rb:273:in `create_or_update'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/persistence.rb:39:in `save'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/validations.rb:43:in `save'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/attribute_methods/dirty.rb:21:in `save'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:240:in `block (2 levels) in save'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:292:in `block in with_transaction_returning_status'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/database_statements.rb:139:in `transaction'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:207:in `transaction'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:290:in `with_transaction_returning_status'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:240:in `block in save'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:251:in `rollback_active_record_state!'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/transactions.rb:239:in `save'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/associations/association_collection.rb:273:in `block in create'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/associations/association_collection.rb:503:in `block in create_record'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/associations/association_collection.rb:480:in `add_record_to_target_with_callbacks'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/associations/association_collection.rb:503:in `create_record'
/opt/local/rvm/gems/ruby-1.9.2-p290/gems/activerecord-3.0.7/lib/active_record/associations/association_collection.rb:271:in `create'

I noticed today that an undefined tag appears to be simply thrown away.

    o = YAML.load('--- !foo "something"')  #=> "something"
    o.class  #=> String

I actually expected it to raise an error, and was somewhat pleased that it did not. But without the tag it's not much use in any case. What would be useful is a YAML wrapper around the object that delegates to it, but also provides a #tag method (and anything else that YAML might need), something like:

    o = YAML.load('--- !foo "something"')  #=> <!foo "something">
    o.tag #=> "!foo"
    o.to_obj #=> "something"

This would make working with YAML documents that use tags much easier, b/c it would mean handlers would not have to be defined upfront and with necessary pre-knowledge. Rather they could be handled on the fly and even dynamically if desired.

I've been thinking about this for some time as I routinely find myself avoiding any use of YAML tags simply b/c of the cumbersome nature of handling them.

From http://redmine.ruby-lang.org/issues/show/1390

Psych cannot dump/load DateTime correctly

% irb --simple-prompt -rpsych
>> (Psych.load Psych.dump DateTime.parse '42-09-23').class
=> Time

It looks like some problems with non-ASCII chars in the filename of assets.
In this case I got (after run of the "rake assets:precompile" command.):

...
rake aborted!
"\xC3" from ASCII-8BIT to UTF-8
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in 'write'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in 'end_document'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in 'visit_Psych_Nodes_Document'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/visitor.rb:10:in 'accept'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in 'block in visit_Psych_Nodes_Stream'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in 'each'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in 'visit_Psych_Nodes_Stream'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/visitors/visitor.rb:11:in 'accept'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych/nodes/node.rb:36:in 'to_yaml'
/usr/local/rvm/rubies/ruby-1.9.2-p180-patched/lib/ruby/1.9.1/psych.rb:166:in 'dump'
/usr/local/rvm/gems/ruby-1.9.2-p180-patched/gems/actionpack-3.1.0/lib/sprockets/assets.rake:51:in 'block (3 levels) in <top (required)>'
...

Thanks in advance.

Parsing the following YAML:

--- 
- &name !ruby/regexp /pattern/i
- *name

yields:

[/pattern/i, "/pattern/i"]

This might be related to issue #24.

This gist demonstrates the issue:

https://gist.github.com/1185322

I derived this isolated example from a problem a user reported to VCR.

Psych.dump of a subclassed Hash with attributes loses those attribute values.

Failing test_hash.rb patch: https://gist.github.com/1482361

This looks like a Psych problem and not a jruby or gem author problem, but its hard to tell.

The command "jruby --1.9 -s gem install" fails on a few gems and gives a stack trace showing PsychParser.java threw an exception. The current versions of the adauth and will_paginate gems both cause the behavior, stack trace shown below.

Using "jruby --1.8" which apparently does not use the Psych YAML parser, works fine as a workaround.

bash-3.1$ jruby --1.9 -S gem install adauth
Fetching: net-ldap-0.3.1.gem (100%)
Psych::SyntaxError: special characters are not allowed
parse at org/jruby/ext/psych/PsychParser.java:282
parse_stream at c:/jruby-1.6.6/lib/ruby/1.9/psych.rb:148
parse at c:/jruby-1.6.6/lib/ruby/1.9/psych.rb:119
load at c:/jruby-1.6.6/lib/ruby/1.9/psych.rb:106
from_yaml at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/specification.rb:490
load_gemspec at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:195
initialize at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:60
each at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package/tar_reader.rb:64
loop at org/jruby/RubyKernel.java:1408
each at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package/tar_reader.rb:55
initialize at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:35
open at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:20
open at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/package.rb:44
from_io at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/format.rb:62
from_file_by_path at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/format.rb:46
open at org/jruby/RubyIO.java:1139
open at org/jruby/RubyKernel.java:297
from_file_by_path at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/format.rb:45
format at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/installer.rb:119
spec at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/installer.rb:129
ensure_required_ruby_version_met at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/installer.rb:386
install at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/installer.rb:156
install at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:297
each at org/jruby/RubyArray.java:1614
each_with_index at org/jruby/RubyEnumerable.java:956
install at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270
execute at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:121
each at org/jruby/RubyArray.java:1614
execute at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115
invoke at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/command.rb:278
process_args at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:147
run at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:117
run at c:/jruby-1.6.6/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:65
(root) at c:/jruby-1.6.6/bin/gem:21

bash-3.1$ jruby -v
jruby 1.6.6 (ruby-1.9.2-p312) (2012-01-30 5673572) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_23) [Windows 7-amd64-java]

I'm facing a problem with psych, that it tries to convert a normal string ("1110-15-1") into a date.
I assume the problem is the following regular expression:

      when /^\d{4}-\d{1,2}-\d{1,2}$/
        require 'date'
        Date.strptime(string, '%Y-%m-%d')

I see that the string above looks like a date but what possible ways are there to serialize a normal string with a date-like format?

Stacktrace

/usr/lib/ruby/1.9.1/date.rb:1022:in `new_by_frags'
/usr/lib/ruby/1.9.1/date.rb:1046:in `strptime'
/usr/lib/ruby/1.9.1/psych/scalar_scanner.rb:45:in `tokenize'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:191:in `visit_String'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:63:in `accept'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:227:in `block in visit_Hash'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:225:in `each'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:225:in `visit_Hash'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:63:in `accept'
/usr/lib/ruby/1.9.1/psych/visitors/yaml_tree.rb:36:in `<<'
/usr/lib/ruby/1.9.1/psych.rb:165:in `dump'
/usr/lib/ruby/1.9.1/psych/core_ext.rb:13:in `psych_to_yaml'

Syck caused me a lot of headaches in the last years (see http://redmine.ruby-lang.org/issues/show/1311) and I'd like to give Psych a try.
Unfortunately, it doesn't seem to be available as a Gem yet.

Is it a matter of time or will Psych be available with Ruby 1.9.2 only?

When trying to yaml-ize Chemical Abstract Service numbers (http://en.wikipedia.org/wiki/CAS_registry_number), the format of the string leads psych to think it's a date.

For instance, the CAS registry number of water is '7732-18-5'. So we get this:

1.9.3p0 :043 > {:cas => '7732-18-5'}.to_yaml
ArgumentError: invalid date
from /Users/rew/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych/scalar_scanner.rb:45:in strptime' from /Users/rew/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych/scalar_scanner.rb:45:intokenize'

The regexp being triggered is thusly:

  when /^\d{4}-\d{1,2}-\d{1,2}$/

There my be a way to alter psych's behavior other than hacking up a copy of the gem, but I don't know what it might be. Unfortunately, I don't have the option to convince the CAS people to not use 4-digit-prefix CAS numbers. :)

Ruby 1.9.2dev does not allow cyclic hash keys since r24149. This breaks test_circular_map in test/visitors/test_yaml_tree.rb (which passed with earlier versions of ruby).

The reason for this change was inconsistency of hashes of Hash [Bug #1298], but I'm not sure if that was a reasonable change.

However, there was some work on this (at least with recursive Hash values) according to [ruby-core:24648][Bug #1852], "Enumerable's #hash methods now raise ArgumentErrors when the structure contains a recursive reference." This was fixed(?) in r24943

Rubyspec only seems to use recursive hash keys up to 1.8.6.

I'm not so sure what should be done here. Either bring it up with ruby-core, or ...?

References:

• r24149 http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=24149
• [ruby-core:24648] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/24648
• Redmin [Bug #1298] http://redmine.ruby-lang.org/issues/show/1298
• Redmine [Bug #1852] http://redmine.ruby-lang.org/issues/show/1852
• r24943 http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=24943
• Rubyspec's Hash: http://github.com/rubyspec/rubyspec/blob/master/core/hash/hash_spec.rb

defaults: &defaults
application: bzz

development:
<<: *defaults
application: WTF
facebook:
id: 42
secret: 424242
scope: email,publish_stream

Everything after <<: *defaults is lost

In core_ext.rb, psych monkeypatches Kernel to remove the "y" method and replace it with the "psych_y" method, which prints the object as YAML. I'm using Parslet to transform a grammar. Parslet uses a "context" object that inherits from BlankSlate to support automatically binding variables in the context of the transformation. I created a parser like this:

transformer = Parslet::Transform.new do
rule(y: simple(:y)) {
y
}
end

Parslet uses method_missing to dynamically bind variables. When I call the "y" method it should look up "y" in the list of bindings and return it. That code looks like this:

def method_missing(sym, *args, &block)
super unless args.empty?
super unless @bindings.has_key?(sym.to_sym)

@bindings[sym]
end

But since y is getting overridden for every object, this instead triggers psych to print out the object. This happens in any app that requires "psych" at any level, which includes anything running inside rails or using activesupport. This caused a huge amount of painful debugging in the course of upgrading to 1.9.3. Would it be possible to not add that method to Kernel? Or at least do something less dangerous, it's not apparent at all what's happening when this crops up. I don't think having a method that prints something is worthy of being patched into every object.

Hash is already handled, but String and Array are not (and perhaps other classes that map to YAML core types). In my system I have subclasses for Hash, String, and Array, so those are the ones I've played with so far.

The two tests below each mirror the ones that are in test_hash.rb. They can probably be copied to all of the other test files, or perhaps made into a mixin for all of the tests.

Failing test_string.rb and test_array.rb patch: https://gist.github.com/1482427

I've started a new YAML schema project. For it to work it needs YPath, so it works with Syck but not Psych. Would it be possible to get YPath support for Psych in future? Thanks.

Using Ruby 1.9.3, I get an "ArgumentError: invalid date" error. however It works on 1.9.2 :)

require 'yaml'
YAML.dump({"year" => "2012-27-01"})