Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Version 2.3.2 won't load in Ruby 1.9.2 on IronWorker #87

Closed
sfcgeorge opened this Issue · 15 comments

4 participants

@sfcgeorge

Locally under Ruby 1.9.3 the gem works fine for me, but when running on IronWorker under Ruby 1.9.2 I got an error about being unable to load unicode.data. I suppose this could either be an issue with Addressable under 1.9.2 or the way IronWorker merges gems.

For now I have reverted to gem version 2.2.8 which works fine.

Let me know if there's any more information you'd like me to provide to track this down, thanks.

@sporkmonger
Owner

That's very likely due to the way the Unicode tables are being loaded, but this kind of thing is strictly a "Patches welcome" scenario. I don't have an IronRuby environment set up, nor any desire to make one.

First step is to pull the master branch and run the tests in the environment that's seeing the issue. Assuming tests fail, you'll want to check the code that performs the unmarshaling of the Unicode tables. Fix the problem, run the tests, send a pull request. Travis Bot will tell you if you broke something in one of the environments I pay attention to. I'll accept the pull request once everything green-bars for all environments.

Otherwise I'll probably close this issue as being far too obscure an environment to worry much about.

@sfcgeorge

Thank you for your fast response.

Ok, since it sounds like the problem is at Iron.io's side I've submitted a bug report with them to see if there's anything they can do. If not I'll have a look at creating a pull request for Addressable, I might have to read up on marshalling.

@sporkmonger
Owner

Can you post the full stack trace?

@sfcgeorge

Certainly. I have had a response from Iron.io but they haven't identified the issue yet. Thanks.

/task/gems/addressable/lib/addressable/idna/pure.rb:322:in `initialize': No such file or directory - /task/gems/addressable/data/unicode.data (Errno::ENOENT)
    from /task/gems/addressable/lib/addressable/idna/pure.rb:322:in `open'
    from /task/gems/addressable/lib/addressable/idna/pure.rb:322:in `<module:IDNA>'
    from /task/gems/addressable/lib/addressable/idna/pure.rb:20:in `<module:Addressable>'
    from /task/gems/addressable/lib/addressable/idna/pure.rb:19:in `<top (required)>'
    from /usr/local/lib/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /usr/local/lib/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /task/gems/addressable/lib/addressable/idna.rb:24:in `rescue in <top (required)>'
    from /task/gems/addressable/lib/addressable/idna.rb:19:in `<top (required)>'
    from /usr/local/lib/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /usr/local/lib/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /task/gems/addressable/lib/addressable/uri.rb:20:in `<top (required)>'
    from /usr/local/lib/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /usr/local/lib/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /task/runner.rb:48:in `<main>'
@sporkmonger
Owner

Ahah. Precisely which version of Addressable is that? My guess is that you didn't load the most recent one, but rather one of the versions I had to yank. Make absolutely sure that this is 2.3.2 and not 2.3.0 or 2.3.1. The file was missing in 2.3.0 and unreadable in 2.3.1, but it should work on 2.3.2.

@sfcgeorge

I've just done a bundle update and I'm on 2.3.2 but I get the same error again, so I guess it must be a different bug, sorry.

@sporkmonger
Owner

OK, try this. gem unpack addressable and see if addressable-2.3.2/data/unicode.data exists.

@langalex

I'm having the exact same issue with 2.3.2. Tha data directory in the gem (after downloading it from IronWorker) is actually completely empty. @sfcgeorge do you have a link to the ticket you submitted to IronWorker?

@sporkmonger
Owner

OK, if you're downloading it from something other than rubygems.org, this sounds like it might be their bug. Maybe they weren't expecting raw binary data in a gem?

@sfcgeorge

Iron.io only just replied to my issue, and I can't work out how to link to their issue system, sorry. It seems they are looking into it now, however. I'll try to keep you guys posted, unless they reply here directly.

@sporkmonger
Owner

Any updates on this?

@sfcgeorge
@pedro

Not sure if this helps, but I just had to debug a issue with missing unicode.data in my project.

Turns out that Fakefs was somehow denying access to it; loading/setting it up after all other test dependencies (and just before the actual tests) did it for me.

@sfcgeorge

I tried switching to the new iron_worker_ng gem which should fix this, but then I found that running workers locally is broken. Their support actually suggested uploading the worker to their servers every time to test changes, ridiculous! Once again their support was very slow and failed to solve my issue so I've decided to run my own worker server using Sidekiq instead, which actually looks better in a number of ways. The problem may still be affecting other people so I've left the issue open, but it really seems more of an issue on IronWorker's side which they won't fix. It baffles me that open source maintainers working for free in their spare time seem to provide vasty better & faster support than this company; they've just lost a customer!

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.