remove diacritics with iconv in ruby on rails not working - ruby-on-rails

i have some problem with removing diacritics with iconv in ruby on rails
here is my code:
class Diacritics
def removeDiacritics(text)
dRemover = Iconv.new("ASCII//TRANSLIT", "UTF-8")
text = dRemover.iconv(text).gsub(/[^a-zA-Z0-9 ]/, '')
end
end
this is output:
1.9.3-p392 :001 > require "diacritics"
/usr/local/rvm/gems/ruby-1.9.3-p392#persoc/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251:in `block in require': iconv will be deprecated in the future, use String#encode instead.
=> true
1.9.3-p392 :002 > remover = Diacritics.new
=> #<Diacritics:0x00000004237068>
1.9.3-p392 :003 > text = "Dánský prezídent"
=> "Dánský prezídent"
1.9.3-p392 :004 > remover.removeDiacritics(text)
=> "Dnsk prezdent"
i expect "Dansky prezident"
server apache on fedora (httpd), using rvm and ruby 1.9.3-p392
Can anybody help me?

You can use the ActiveSupport::Inflector.transliterate method.
ActiveSupport::Inflector.transliterate("Dánsky prezídent") # => "Dansky prezident"
If you need this for a url slug, it's even easier.
"Dánsky prezídent".parameterize # => "dansky-prezident"

Related

Application controller has no subclasses?

Just curious as to why this happens in the rails console:
Loading development environment (Rails 4.1.5)
2.1.2 :001 > require 'application_controller'
=> true
2.1.2 :002 > ApplicationController
=> ApplicationController
2.1.2 :003 > ApplicationController.subclasses
=> []
2.1.2 :004 > ::ApplicationController.descendants
=> []
I have this controller
class MyController < ApplicationController
end
So I'm expecting ApplicationController.subclasses #=> [MyController], however, I'm getting an empty array :(
Well, credit goes to MrYoshiji, but here's how you display subclasses.:
Loading development environment (Rails 4.1.5)
2.1.2 :001 > require 'application_controller'
=> true
2.1.2 :001 > require 'my_controller'
=> true
2.1.2 :002 > ApplicationController
=> ApplicationController
2.1.2 :003 > ApplicationController.subclasses
=> [MyController]
Lazy load means an object doesn't exist in memory until it is specifically called during runtime. My second command, require 'my_controller actively references a subclass of ApplicationController and so it appears when we list its subclasses with the .subclass method.

Error using Log4r

I have a problem using Log4r.
uninitialized constant Log4r::Logger::RootLogger
I tried this, but still got an error:
>> require "log4r"
=> true
>> Log4r::DEBUG
NameError: uninitialized constant Log4r::DEBUG
>> Log4r::Logger.root
=> uninitialized constant Log4r::Logger::RootLogger
from /var/lib/gems/1.9.1/gems/log4r-1.1.11/lib/log4r/staticlogger.rb:5:in `root'
from (irb):5
from /usr/bin/irb:12:in `<main>'
Your problem with Log4r::Logger.root is version depending (the actual version 1.1.11 has this problem).
You may use the previous log4r-version 1.1.10:
gem 'log4r', '<=1.1.10' #or '= 1.1.10'
require 'log4r'
Log4r::Logger.root
log4r defines the constants like Log4r::DEBUG with the creation of the first logger.
You need a Log4r::Logger.new('dummy') before you have access to the level constants.
require 'log4r'
p defined? Log4r::INFO #false
Log4r::Logger.new('dummy')
p defined? Log4r::INFO #constant -> is defined
Some background:
There is a constant Log4r::Log4rConfig::LogLevels defining the different levels. The level-constants are defined, when the first logger is created. You may define them also with Log4r.define_levels(*Log4r::Log4rConfig::LogLevels)
This technique allows it to create loggers with different logging levels.
AlthoughLog4r::Logger.root no longer enables the constants, the code included later on in the answer you referred to does introduce the constants:
Log4r.define_levels(*Log4r::Log4rConfig::LogLevels)
per the following:
MacbookAir1:so1 palfvin$ irb
2.0.0p247 :001 > require 'log4r'
=> true
2.0.0p247 :002 > Log4r.define_levels(*Log4r::Log4rConfig::LogLevels)
=> 5
2.0.0p247 :003 > Log4r::DEBUG
=> 1
2.0.0p247 :004 >

Ruby on Rails SNMP gem - no response from device

I'm using the SNMP gem in a Rails app to control a Cisco switch. The "get" features of the Gem work, and I can retrieve values from the devices, but the "set" feature isn't working so well...
From the command line, the SNMP commands work properly:
bash-4.1# snmpset -v2c -c private-string 192.168.3.1 .1.3.6.1.2.1.2.2.1.7.11 i 2
IF-MIB::ifAdminStatus.11 = INTEGER: down(2)
bash-4.1#
But when I try to set the same OID using the Gem, I get "no response from 192.168.3.1"
In both the actual app and in IRB:
bash-4.1# irb
2.0.0-p0 :001 > require 'snmp'
=> true
2.0.0-p0 :002 > include SNMP
=> Object
2.0.0-p0 :003 > SNMP::Manager.open(:host => "192.168.3.1", :community => "private-string") do |manager|
2.0.0-p0 :004 > varbind = VarBind.new("1.3.6.1.2.1.2.2.1.7.11", "2")
2.0.0-p0 :005?> manager.set(varbind)
2.0.0-p0 :006?> end
SNMP::RequestTimeout: host 192.168.3.1 not responding
from /usr/local/rvm/gems/ruby-2.0.0-p0/gems/snmp-1.1.1/lib/snmp/manager.rb:293:in `set'
from (irb):5:in `block in irb_binding'
from /usr/local/rvm/gems/ruby-2.0.0-p0/gems/snmp-1.1.1/lib/snmp/manager.rb:205:in `open'
from (irb):3
from /usr/local/rvm/rubies/ruby-2.0.0-p0/bin/irb:16:in `<main>'
2.0.0-p0 :007 > exit
I can run the snmpset from the command line on the same machine, and it works correctly, but not using the gem.
Try varbind = VarBind.new("1.3.6.1.2.1.2.2.1.7.11", SNMP::Integer.new(2)) so that the varbind type is correct.

Rails generate wrong pluralize form

I use Ruby 1.9.3 and Rails 3.2.9, when I do the following in a rails console:
1.9.3p125 :003 > "foot".pluralize
=> "foots" # shouldn't it be "feet"?
1.9.3p125 :004 > "tooth".pluralize
=> "tooths" # shouldn't it be "teeth"?
1.9.3p125 :009 > "goose".pluralize
=> "gooses" # shouldn't it be "geese"?
is that a bug in rails pluralize or I did something wrong?
You can configure the rails inflector. There should be an initializer file in your application to do so: config/initializers/inflections.rb
You can then add a call to "teach" rails the new rule:
ActiveSupport::Inflector.inflections do |inflect|
inflect.irregular 'tooth', 'teeth'
end
After you restart the server/console the new pluralization should be in place.

ruby 1.9.3-p194 rails 3.2.9 BigDecimal to_f always outputs 0.0

Since about last week, my usually working rails project started behaving badly in regards to BigDecimal.to_f. Every BigDecimal number gets output as 0.0 when calling to_f:
~/development/rails_project> rails c
Loading development environment (Rails 3.2.9)
1.9.3p194 :001 > BigDecimal.new('5').to_f
=> 0.0
I'm running Ruby 1.9.3 patch level 194, and Rails 3.2.9, as I always have. Some co-workers who also work on the same project using the same versions don't have this issue.
Also tried with Ruby 1.9.3 patch level 362 with the same results. Has anyone had the same problem and knows how to overcome it?
Thanks.
EDIT:
My problem is not with the to_s function, but the to_f. I probably over-simplified, because my issue is with number_to_currency:
~/development/rails_project> rails c
Loading development environment (Rails 3.2.9)
1.9.3p194 :001 > include ActionView::Helpers::NumberHelper
=> Object
1.9.3p194 :002 > BigDecimal.new('5').to_s('F')
=> "5.0"
1.9.3p194 :003 > BigDecimal.new('5').to_s
=> "5.0"
1.9.3p194 :004 > BigDecimal.new('5').to_f
=> 0.0
1.9.3p194 :005 > number_to_currency(5)
=> "€ 0,00"
With some debugging, I narrowed it down to the number_with_precision method, more precisely to the line:
rounded_number = BigDecimal.new(number.to_s).round(precision).to_f
If I output the different parts of this line, I get the following results:
number = 5.0
number.to_s = "5.0"
precision = 2
BigDecimal.new(number.to_s) = 5.0
BigDecimal.new(number.to_s).round(precision) = 5.0
BigDecimal.new(number.to_s).round(precision).to_f = 0.0
Any clue?
Just a shot in the dark: This might be a locale-dependant formatting issue of the Ruby/Rails console.
Try this:
BigDecimal.new('5').to_s('F') # Should be "5.0"
BigDecimal.new('5').to_i # Should be 5
If this ouputs the expected result, then it is just a formatting issue of the console. The to_f method actually returns the correct result, but the console calls another to_s on the result in order to print it. In that case you should be able to reproduce the problem with 5.to_f, too.

Resources