When I load andand in Ruby 1.9 I get the warning
andand.rb:111: warning: undefining 'object_id' may cause serious problem
Does anyone know a way, other than modifying andand to not remove object_id, to avoid this warning?
Thanks!
You're in luck - it was just patched with a fix for this issue.
Unfortunately, as of 2011-03, the gem has not been published with this patch in place. However, there is a fork which sole purpose is to have that patch: ryansch-andand
Good news! Version v1.3.3 was pushed to RubyGems on 2012-03-28, and includes this fix.
Related
ruby - 2.7.2
rails - 6.0
paperclip - 6.1.0
I am getting following warning in my console, while using paperclip gem with ruby 2.7.2
/Users/***/.rvm/gems/ruby-2.7.2/gems/paperclip-6.1.0/lib/paperclip/url_generator.rb:68: warning: URI.escape is obsolete
I know there are no maintainers for paperclip and it is deprecated but I cannot use active storage as I found paperclip is the easiest and best way for implementing attachments. How can I solve this warning ?
When you say "solve" the warning it's not quite clear what you might consider to be an acceptable solution. But you could:
a) Ignore the warning so long as you are sticking with these versions of Ruby and Rails, as it does not mean that anything is broken.
b) Write some code to suppress this specific warning, though I'd probably not do this as you'd increase the chance of forgetting about the issue, and then ending up with a more acute and time-sensitive problem down the road, if you upgraded part of your system to where URI.escape was no longer available.
c) Do what I've done in my Rails application, which is switch to a forked and maintained version of Paperclip, KT-Paperclip. If you wanted to update to the minimum version number that addresses these deprecation warnings, you'd choose 6.4.
Wellll the right answer is to do something better for your codebase as #UptDogTT suggests... but if you just need a get-it-done answer, this monkey patch adds URI.escape back using equivalent functionality. Add it as an initializer:
module URI
def self.escape url
URI::Parser.new.escape url
end
end
Hi I am building a gem which depends on the multi_json gem, which is basically adapters to all other json encoder/decoders out there.
So an user filed an issue on my gem. He has issues because multi_json has a small bug in one of the adapters, which is later fixed on multi_json's end, so it is not really my issue.
I am wondering if I should change my gemspec to hardcode the dependency to the fixed version of multi_json. I thought it would be easier to just tell the user to explicitly specify to use the fixed version of multi_json. This way my dependency won't be too strict and conflict with other gems which use multi_json.
What are the thoughts on this?
You don't have to lock dependency version entirely, just make sure that you have release that have above-mentioned bug fixed. For instance,
gem 'multi_json', '> 1.9.1'
It will be on rubygems sooner or later and you're definitely not interested in encountering the same bug twice.
My opinion is that the reliability of your library in the present is more important than future development inconveniences, which may or may not occur.
As for what to tell your users, they should've already heard (and if they haven't you could remind them of this in the README.md) that most of the critical problems usually are solved within the day and can be found in master. So if they want to take advantage of the latest fixes (and the freshest new bugs), they could specify github as a source:
gem 'your_gem', github: 'lulalala/your_gem'
MagLev tries to be compatible with ruby 1.8.7
So it seems to me that Jekyll should be able to run on it...
And based on this previous question, seems that even some rails applications can run on it...
But has anyone actually tried it?
What were the problems you had?
If you haven't tried it, do you anticipate any major problems?
TIA
I just tried Jekyll on Maglev's 1.9 branch, and it doesn't work. Maglev falls down when using anything with C extensions; in this case, it's Jekyll's dependency on posix-spawn.
You might wanna check out the docs regarding the state of C extensions on Maglev.
AFAIK, Jekyll doesn't really have persistence (besides static files), so I'm not sure what you'd gain from using Maglev. You can definitely have a lot of fun with Maglev and Sinatra, give them a shot.
When I run my Rails app in WEBrick on Ubuntu, after upgrading to ruby-1.9.3-p327, I receive the following error:
[rake --tasks] /home/dsilver/.rvm/gems/ruby-1.9.3-p327/gems/em-dir-watcher-0.9.4/lib/em-dir-watcher.rb:7: Use RbConfig instead of obsolete and deprecated Config.
Any idea what's going on?
I've seen some posts connecting this to ImageMagick on Windows. I am on Ubuntu, but the app does use ImageMagick, and the ImageMagick functionality appears to have broken since the ruby upgrade from 1.9.2 to 1.9.3. I suspect a connection.
Thanks!
The Config module has been renamed to RbConfig. It’s still possible to use the old name, for backwards compatibility, but Ruby issues a warning if you do.
The em-dir-watcher gem uses the old name, and so you see the warning when it’s loaded. Someone has already sent a pull request fixing this, however the last update to em-dir-watcher was over two years ago so it might not get merged.
This is a warning that is generated, not an error, so your code should actually still work okay. If you really want to get rid of the warning you could add something like this before you require 'em-dir-watcher':
Object.send :remove_const, :Config
Config = RbConfig
This defines Config to be the same as RbConfig, which is what Ruby does anyway, but prevents the warning.
You can do (not recommended):
Go to the file ../lib/ruby/1.9/rbconfig/obsolete.rb
Edit the file, the change is commenting the line #warn ...
With that change, eliminated the advice "warn"
Using jruby 1.5.1
In a pretty simple cronjob that uses gems:
dbi
dbd-jdbc
jdbc-mysql
It also uses a pure Java JDBC driver in a jar, jtds-1.2.5.jar
Every time I run it, I get this in STDERR (which is annoying my cronjob monitoring utilty which thinks anything on stderr may be a problem)
/usr/local/rvm/gems/jruby-1.6.5.1/gems/deprecated-2.0.1/lib/deprecated.rb:199 warning: already initialized constant Deprecate
?? Any ideas? What's going on, what can I do about it? Not sure which of these gems depends on 'deprecated' library or what version, any easy way to find out?
Ah, okay, figured it out:
[rochkind#catalyst pull_reserves]$ gem dependency dbi
Gem dbi-0.4.5
deprecated (= 2.0.1)
But 0.4.5 is the most recent version of 'dbi', and it is locked to 2.0.1 of 'deprecated'. There is a more recent 3.0.0 version of deprecated.
Okay... not sure what my question is now, except if anyone can figure out more about what's going on, and what my actual options are. I guess report as an issue to 'dbi' gem, hoping it's got some maintainers who care, I dunno.
more update: Okay, and there's already an issue filed for this, from August. https://github.com/erikh/ruby-dbi/pull/8 Looks like the gem is not very maintained. sigh. sometimes ruby community really frustrates me.
I think this is what you need:
Suppress Warnings From Ruby
A comment there mentions the Rails method to silence warnings, but I don't think you're using Rails.
EDIT: I found slightly cleaner code here:
https://mislav.net/2011/06/ruby-verbose-mode/
EDIT: Note: A commenter below seems to disagree with the blog entry mentioned above. I'm not expressing agreement or disagreement with the blog entry and I'm not opinionating on the goodness or badness of Ruby's verbose mode, merely crediting the author for the slightly cleaner code I found there.
I think this is what you'd do:
module Kernel
def silence_warnings
with_warnings(nil) { yield }
end
def with_warnings(flag)
old_verbose, $VERBOSE = $VERBOSE, flag
yield
ensure
$VERBOSE = old_verbose
end
end unless Kernel.respond_to? :silence_warnings
# assuming the warning is being generated when the dbi module is loaded...
silence_warnings { require 'dbi' }