Is there a way to disable ruby 2.0.0 YAML's suffixing with ruby type info?
I just upgraded to ruby 2.0.0 and I'm having YAML problems. I read-update-write a yaml file that previously looked like this
test:
test2:
somevar: hello
When I feed this into ruby 200, it reads OK but writes:
test: !ruby/object:Hash
test2: !ruby/object:Hash
somevar: hello
When I rerun the program YAML.load reads nothing.
myH = YAML.load_file( YAML_FPATH )
puts "Yaml as Hash:" + myH.inspect
>> Yaml as Hash: {}
Curiously, if I pass the "test: !ruby/object:Hash" version of the file to ruby 1.8.7, it reads the suffixed file OK and writes a non-suffixed file.
Problem found: I modified hash.to_yaml so that it sorts the keys. Since my code is based on hash.to_yaml 1.8.7 I need to revise it based on hash.to_yaml 2.0.0.
Related
I'm trying to upgrade a server that has ruby scripts developed by another person. I'm a perl/php developer and no little about ruby, just trying to get the scripts to work that was developed with Ruby 1.8 and the scripts seems to behave differently handling arrays in the newer version. The script was not matching iterated folders with a config file array with the folder names and I believe I've boiled it down to the way the YAML config file is converted to an array. I put together this simple script:
require 'rubygems'
require 'yaml'
config_filename = File.expand_path(File.dirname(__FILE__) + "/testruby.yml")
#config = YAML.load(File.open(config_filename))
puts #config
The YAML testruby.yml config file looks like this:
1_01:
name: Monday Show
suffix: showM
program_id: 123
segment: 1
dated: false
1_02:
name: Monday Show
suffix: showM
program_id: 123
segment: 2
dated: false
1_03:
name: Tuesday Show
suffix: showT
program_id: 124
segment: 1
dated: true
When I run this on the original server with Ruby 1.8, the result is:
1_03program_id124nameTuesday Showsegment1suffixshowTdatedtrue1_02program_id123nameMonday Showsegment2suffixshowMdatedfalse1_01program_id123nameMonday Showsegment1suffixshowMdatedfalse
But when ran on the new server with Ruby 2.3 I get a array:
{101=>{"name"=>"Monday Show", "suffix"=>"showM", "program_id"=>123, "segment"=>1, "dated"=>false}, 102=>{"name"=>"Monday Show", "suffix"=>"showM", "program_id"=>123, "segment"=>2, "dated"=>false}, 103=>{"name"=>"Tuesday Show", "suffix"=>"showT", "program_id"=>124, "segment"=>1, "dated"=>true}}
It even removes the underscore from the folder name key in the config file. For this reason, later in the script, calls to #config[1_01] does not match of course. Is there a way to get the array to build like version 1.9 so the rest of the script works as designed?
One more thing to note, not sure if it related to the issue. The require 'yaml' line was not present in the script, I added after receiving this error when ran:
testruby.rb:4:in `<main>': uninitialized constant YAML (NameError)
Well, it seems all I had to do was enclose the YAML keys in quotes and now the hash object includes the underscore in the keys and the rest of the script works!
When we install Rails, we get this rails "executable":
#!/usr/bin/env ruby
#
# This file was generated by RubyGems.
#
# The application 'railties' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0"
if ARGV.first
str = ARGV.first
str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding
if str =~ /\A_(.*)_\z/ and Gem::Version.correct?($1) then
version = $1
ARGV.shift
end
end
gem 'railties', version
load Gem.bin_path('railties', 'rails', version)
I'm wondering what the point of doing force_encoding("BINARY") is on that String. What possible values could it be that force_encoding is necessary? I would think that people would only specify versions using numbers and letters here.
This isn't a rails specific thing - it's a wrapper rubygems will generate for any ruby executable in a gem. The call to force_encoding was added in 6bf71914
The reason for the change is that the first argument might not be a version at all - we want to test if it is a version, but it could be anything and we don't want the regex check to blow up. For example some executables accept a list of file names as arguments, and those file names could be invalid in the default external encoding used by ruby.
There is a bit more discussion on the issue which prompted this change.
I have a Ruby script that iterates over each line of a text file.
In Ruby 1.8.* using content.each do |line| works fine, but in Ruby 1.9.* that does not work, and I need to use content.each_line do |line|.
Since this script will be used by several different people, I need to be able to use the right method depending on their version of Ruby.
Is there a way to do this?
The global constant RUBY_VERSION contains the version of the currently running Ruby. So this script will do what you want:
if RUBY_VERSION < "1.9.2"
# code for 1.8.7
else
# code for 1.9.2+
end
If the inner code of the each_line is equal with 1.8.* and 1.9.*, the following approach is more DRY:
each_selector = RUBY_VERSION < "1.9.2" ? :each : :each_line
content.send(each_selector) do | line|
# ...
end
I'm having a weird issue with Ruby hashes on windows. I'm loading the following YAML file and parsing it as a hash:
tasks:
- clone_skeleton, <skeleton_path>
- summit_capify, <skeleton_path>
I'm using YAML.load() to load the file into a hash. If I print out hash.keys tasks is listed as a key but if I do hash.has_key?("tasks") I get back false. However if I change the yaml to this
directory_structure:
tasks:
- clone_skeleton, <skeleton_path>
- summit_capify, <skeleton_path>
hash.has_key?("tasks") returns true but hash.has_key?("directory_structure") returns false. I haven't tested in Linux but I don't seem to be having this problem on OS X, just Windows. I'm using Ruby 1.9.2 and have tested in Cygwin and using the standard command prompt.
I don't know if this is a ruby bug, a problem with my YAML or something else. Any ideas?
UPDATE: Looks like this is fixed in Ruby 1.9.3
Is it possible the keys are Symbols and not Strings? Trying has_key?(:tasks).
Whenever you're debugging, don't do puts hash.keys, but do puts hash.keys.inspect - the latter indicates exactly what's going on.
Or you may want to do puts hash.inspect.
I've installed the latest version of the stanfordparser and the ruby wrapper library for it. When trying to test it with a simple example from the website:
vi test.rb:
require "stanfordparser"
preproc =
StanfordParser::DocumentPreprocessor.new
puts
preproc.getSentencesFromString("This
is a sentence. So is this.")
ruby -rubygems test.rb
This
is
a
sentence
.
So
is
this
.
This is a sanity check really - am I doing something wrong, or is this a bug in the parser or wrapper?
You might be confused about how puts is formatting the output. Try this:
x = preproc.getSentencesFromString("This is a sentence. So is this.")
puts x.inspect
to make sure that you're getting what you're supposed to be getting.