ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

2.0.0RC3 - YAML Parser fails in ruby 1.9 (Bug #503)


Added by Gary Verhaegen at 2011-07-01 09:32 am. Updated at 2011-07-26 12:50 pm.


Status:Closed Start date:2011-07-01
Priority:Low Due date:
Assignee:Eric Davis % Done:

0%

Category:Libraries
Target version:2.0.0
Remote issue URL: Affected version:unstable

Description

When I try to launch the rails server, I get a huge stack trace that begins with

/opt/local/lib/ruby1.9/1.9.1/psych.rb:148:in `parse': couldn't parse YAML at line 934 column 66 (Psych::SyntaxError)
        from /opt/local/lib/ruby1.9/1.9.1/psych.rb:148:in `parse_stream'
        from /opt/local/lib/ruby1.9/1.9.1/psych.rb:119:in `parse'
        from /opt/local/lib/ruby1.9/1.9.1/psych.rb:106:in `load'
        from /opt/local/lib/ruby1.9/1.9.1/psych.rb:206:in `load_file'

This is Mac OS X, and Ruby is installed from MacPorts, so the paths are misleading; I use Rails 2.3.12 and Ruby version is actually
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10]

As I understand it, support for ruby 1.9 is not a primary objective of the project at the moment, but this is actually pretty easy to repair. The basic problem is that the stack trace does not show which files are involved; a little digging revealed the culprits to be config/locales/en.yml and config/locales/pt-BR.yml, specifically the four strings containing c:\.

The problem is solved by replacing the c:\ with c:\\; I have done that tremendous amount of work on my repo at github, for which I have made a pull request to Eric Davis. (This is actually a bit of a white lie, as there are synchronization issues between me posting this bug report and me wanting to have the correct ticket number in the commit message.)


Associated revisions

Revision 0d813146
Added by Gary Verhaegen at 2011-07-02 01:01 am

Solves #503: parsing translations with psych in ruby 1.9

History

Updated by Eric Davis at 2011-07-01 04:47 pm

I'll take a look at this. I could launch the rails server with my 1.9.2 but this might be a problem with 1.9.2's syck vs psych parser.

  • Assignee set to Eric Davis

Updated by Eric Davis at 2011-07-01 11:20 pm

Confirmed and fixed in 0d81314. Thanks for the patch and pull request.

  • Category set to Libraries
  • (deleted custom field) set to unstable
  • Status changed from Ready for review to Closed

Updated by Etienne Massip at 2011-07-19 01:12 pm

Hi, looks like you missed some of these errors, see http://www.redmine.org/issues/8847.

Updated by Gary Verhaegen at 2011-07-19 02:26 pm

Your comment intrigued me, so I checked. My versions of the locales files do not seem to match yours. For example, in the french locale, I do indeed have some unescaped backslashes, but they correspond to text_{git,mercurial}_repo_example instead of your text_{git,mercurial}_repository_note, and, more interestingly, they are not part of a string enclosed in double quotes.

I do not know much about the differences between chiliproject and redmine, but I guess translation files have diverged, and that explains the differences in our files. What's interesting, however, is that while this causes an error:

text_mercurial_repo_example: "local repository (e.g. /hgrepo, c:\hgrepo)" 

this seems to be perfectly fine by the ruby 1.9 YAML parser:
text_mercurial_repo_example: local repository (e.g. /hgrepo, c:\hgrepo)

Updated by Etienne Massip at 2011-07-19 03:34 pm

Gary Verhaegen wrote:

(...) I do indeed have some unescaped backslashes, but they correspond to text_{git,mercurial}_repo_example instead of your text_{git,mercurial}_repository_note, and, more interestingly, they are not part of a string enclosed in double quotes.

Indeed, strings were extracted from RepositoryHelper by Toshi in Redmine then Simon Courtois extracted them in CP instead of updating the locales files.

What's interesting, however, is that while this causes an error:
[...]
this seems to be perfectly fine by the ruby 1.9 YAML parser:
[...]

Right, it seems it takes the full string as a non-parsable one. Good to know =)

Updated by Eric Davis at 2011-07-22 03:31 pm

Etienne Massip:

So is there still a problem parsing the current locales with 1.9.2? I only had errors in the en and pt-BR locales, the others parsed fine with psych.

Updated by Gary Verhaegen at 2011-07-26 12:50 pm

Everything is fine in the chiliproject translations; as explained above, if the string is not quoted in the YAML file, the backslashes do not need to be escaped. They were quoted in the redmine translations but not in the chiliproject ones, so no more problem here, at least until someone decides to quote them. I know nothing about the YAML format, so I do not know whether there would be any incentive to quote them in the future, but right now everything is fine.

Also available in: Atom PDF