Could you figure out which line is causing that nil?

Looks like the nil is "path" being passed to "<<" on a Digest::MD5 instance, if the line numbers are to be trusted.

The path value comes from the sole class that includes SpriteMethods -- SpriteMap -- in logic it uses to calculate a filesystem path to a sprite (method from_uri). Relevant line:

path, name = Compass::SpriteImporter.path_and_name(uri)

It does not appear to be possible for path_and_name to return nil (it either returns a literal array or raises), so this could be a bug in how we destructure the resulting value into path and name.

Ok, the destructuring theory didn't pan out...it works fine. The next possibility would be that $1 in path_and_name is coming back nil even though we have a match. I'm not sure how that would happen.

    SPRITE_IMPORTER_REGEX = %r{((.+/)?([^\*.]+))/(.+?)\.png}
...
    def self.path_and_name(uri)
      if uri =~ SPRITE_IMPORTER_REGEX
        [$1, $3]
      else
        raise Compass::Error, "invalid sprite path"
      end
    end

Given the regexp I don't see how that could happen...so it's something really weird or I'm chasing my tail. :-(

@craigmcnamara Could you perhaps dig into this a bit deeper, maybe starting with the methods I listed above? You know the codebase much better than us, obviously.

I'll see if I can setup a clean reproduction of the bug.

So this is my reproduction of jruby-head vs MRI 2.1.5, it looks like a Regex issue.

https://gist.github.com/craigmcnamara/a4f28434a3d4aa950c18

So unfortunately this passes on both JRuby and MRI and is the most simple reproduction of what I thought the bug was.

  CONSTANT_ASSIGNED_REGEX = %r{((.+/)?([^\*.]+))/(.+?)\.png}
  it "tests a jruby regex matches" do
    "letters/*.png" =~ CONSTANT_ASSIGNED_REGEX
    assert_match 'letters', $1
    assert_match 'letters', $3

    match_data = "letters/*.png".match(%r{((.+/)?([^\*.]+))/(.+?)\.png})
    assert_match 'letters', match_data[1]
    assert_match 'letters', match_data[3]
  end

recent builds tend to be 💚 with jruby-head ... so maybe this is no longer relevant (was resolved) ?