Skip to content

Fixed issue #1859: ArgumentError for to_xs after instruct! is called #2076

wants to merge 5 commits into from

10 participants

x =

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.

@bfolkens bfolkens Fixed issue #1859: ArgumentError for to_xs after instruct! is called c1da803

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.

joshsz commented Nov 2, 2011

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?

hron84 commented Mar 6, 2012

If anyone would like work around this bug until rails developers finally takes care about it, then:

# config/initializers/fix_rails_2076
require 'builder'

module Builder
  class XmlBase
    # We aren't under Ruby 1.9?
    unless ::String.method_defined?(:encode)
      def _escape(text)

Terrible, but works.

thbar commented Mar 16, 2012

@hron84 thanks!

Ruby on Rails member
NZKoz commented Apr 22, 2012

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.

Ruby on Rails member
NZKoz commented Apr 22, 2012

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.

hron84 commented Apr 23, 2012

@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

Ruby on Rails member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.