x = Builder::XmlMarkup.new
Gives the following stack trace with Ruby 1.8.7, Builder 3.0.0, Rails 3.1.0.rc[1-4]:
Looks like an incompatibility between fast_xs and Builder 3.0.0, when it's included and overridden in ActiveSupport. The Builder 3.0.0 version takes an encoding argument.
Look at the file you edited. The indentation is terribly messed up. You should use two spaced for indentation.
Shouldn't this be fixed in fast_xs ? The problem could occur similarly with any other library using it and not depending on activesupport.
Fixed issue #1859: ArgumentError for to_xs after instruct! is called
Yikes, sorry about that - I updated the commit to fix the whitespace issues.
From what I could tell this is a pretty specific issue to active_support where it replaces the Builder to_xs implementation with fast_xs. The fast_xs extension's method doesn't accept the encoding argument that the newer versions of Builder use. In reality, we're losing an argument by doing this so throwing an exception may be desired instead of this hack, or just not including fast_xs when the argument requirements aren't the same.
I say +1 this patch because it seems like ActiveSupport should have the responsibility of making sure the method signatures are compatible with both implementations if they want swap it out.
Merge remote branch 'rails/3-1-stable' into 3-1-stable
Merge branch 'rails/3-1-stable' into 3-1-stable
Merge remote-tracking branch 'rails/3-1-stable' into 3-1-stable
Agreed with @brianmario. If ActiveSupport is changing how Builder behaves, it should ensure it presents the same API.
I cant believe that its been 8 months and this still has not been pulled into Rails. WAT?
If anyone would like work around this bug until rails developers finally takes care about it, then:
# We aren't under Ruby 1.9?
Terrible, but works.
Pulling this fix in involves monkeypatching a library which is still under active maintenance and perfectly capable of fixing it themselves. Accreting junk like this in our code base really isn't an appropriate fix.
Unless we get a definitive statement from @jimweirich that builder won't ever ship a fix for this arity problem, then adding the monkeypatch to our codebase is the wrong decision.
We could remove all the monkeypatching we have ourselves so we're just using 'raw' builder, but accreting more stuff that'll be legacy cruft soon isn't really a sustainable fix.
@NZKoz I understood this, however many developers wouldn't like waiting an undefined time for statement of builder's author, especially because this bug is not 'something issues a warning' but a fatal error.
To make clear: I would not recommend to include this patch into rails' codebase I know my solution is an ugly monkeypatching, I suggest use my fix until this bug is fixed and if reader cannot wait (or stuck on an older version of stuffs) until somebody, somewhere, somehow fix it.
@NZKoz Hi, @jimweirich has fixed this issue in builder 3.1.0. Alas, 3-1-stable, 3-2-stable and master are all locked down to builder ~> 3.0.0. I've asked Jim if he can release a patch version so rails users can use the change, but it seems that rails shouldn't be locked down to ~> 3.0.0 if we're depending on builder to fix the issue. The relevant pull request: jimweirich/builder#12
This has been fixed with builder 3.0.1, run bundle update builder to get the new version with the proper fix. Please see @jonkessler link to builder for the discussion. Closing here, thanks.
bundle update builder