to_xs takes an encoding argument in 1.9.2 but doesn't in 1.8.7. This causes this method to fail with an ArgumentError when used in 1.8.7.
in Ruby 1.8.7 arity of method to_xs is 0 - in 1.9.2 it takes encoding
Just ran into this myself & patch looks good.
I just sent an email to the maintainer, I hope it gets fixed soon.
Does someone knows why is this hitting on us now? Builder hasn't changed since last year...
Presumably because Rails 3.1 bumped the bundler version it depends on to 3.0, thus automatically exposing many people to this problem.
@nielsomat What does bundler has to do with that?
Sorry typo, meant builder of course.
Several people have pinged me on this, so I'm looking into it. But for me, all the unit tests in 1.8.6, 1.8.7-p330, 1.8.7-p352, and 1.9.2-p136 are passing. I haven't been able to trigger the problem locally.
Do you have a unit test that exposes the problem code? What version & patch level of Ruby are you using when this happens?
1.8.7-p334 for me.
just calling to_xml on a collection of records.
@jimweirich: good point, I will create a test.
My bad, I was unable to reproduce the situation in tests.
This is (almost certainly) caused by activesupport substituting to_xs by fast_xs in lib/activesupport/core_ext/string/xchar.rb, which takes no arguments.
So builder is not at fault here. We'll work with monkey patching on our project for now ...
@elisehuard It makes sense. Thanks for investigating.
Thanks. Looks like the problem will be handled on the rails end.
Thx for fix.
Thanxxx man!!!! its saved my time... :-)
@jimweirich this is actually a bug in builder still and the fixes in rails will involve a clusterfuck of monkeypatches to avoid the problem
A Fix in builder to not assume that to_xs takes an argument would be great.
At the moment the 3 packages in question are each saying that we should wait for a different package to supply a fix.
It would be more convenient to people using these packages if all three packages issued a fix that avoids the problem whether or not the other packages have, thus reducing the coupling between versions.
@jimweirich Rails is clearly not patching this. I would really appreciate it if this change were pulled in to builder. Currently, we have to monkey patch _escape in all of our apps because of the conflict.
I reopened this and applied the changes. builder-3.1.0 has the fix. Let me know if it works for you.
@jimweirich The change looks good, but I just realized that Rails locks you down to ~> 3.0.0, so I am unable to update my builder version. Would it be at all possible to make a patch release (3.0.1, for example), so that Rails users can use the fixed version?
I pushed a 3.0.1 version of the gem. It's identical to 3.1.0, but should play nicely with rails requirements.
Thanks, Jim! Works great.