From: Suraj Kurapati <snk@...>
Date: 2008-01-13T07:57:58+09:00
Subject: Re: does ruby's strftime not attempt POSIX-compliance?

Jochen Hayek wrote:
> Pls let me assure you in the beginning of this note, that it's
> not my intent to start any flame war and also that I do not want
> to offend anybody honorable.

Ah, don't worry about it. In general, the audience here on ruby-talk
is quite open-minded and respectful -- or so I would like to think. :-)

> It's only about reasonable employment of good willing
> programmers' resources and constructive use of pre-existing
> software and standards like glibc, POSIX, ...

Good, you are correct to be concerned!

>>> Suraj Kurapati wrote:
>>>> See this post for an example: 
>>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/57474
> 
> The article referred to here talks about an interpreter patch
> dated around 2002, that did not make its way into "MRI" by now, 
> de facto it's not part of 1.8.6, neither is it part of 1.9, let's
> call it dead therefore. I would love to learn, that I am not
> right there, but I do fear, I am.
> 
> If I understood Matz correctly, then "1.9 calls setlocale() ...
> for LC_TYPE" *internally* and obviously setting any of the LC_*
> environment variables of a ruby script has *no* *effect*
> *whatsover*.

Hmm, I thought Matz said that Ruby 1.9 does this:

  setlocale( ENV['LC_TYPE'] )

instead of this:

   setlocale( 'C' )

Matz, would you please clarify?

> Apparently these env. variables get overwritten within the
> interpreter, let's consider this locale setting as "*frozen*", and
> is my assumption correct, that various rather "central" software makes
> uses of this *frozen* locale, I mean e.g. all the library code, 
> that handles HTTP protocol date/time strings.

Correct.  A Ruby 1.8 script can only change the locale using the 
ruby-locale library.

> Therefore that "central" code would break, if the interpreter and
> its "kernel library code" would get the *frozen* locale setting
> removed.

Good point.  I never realized this!

> But wouldn't it still be a good idea, to give the world, what
> (g)libc actually already implements, I mean all the features
> directed by those LC_* env. variables, e.g. language/region
> dependant date/time strings, currency, thousands/decimal
> separators, etc. pp.?!!!!

Agreed.

> I mean it shouldn't be that hard to cure the code, that depends
> in turn on that frozen locale setting, and further on to remove
> this freezing, right?

Ah, you are hinting at a setlocale() method that accepts a block:

  # assuming that Ruby has a Kernel#__set_locale__ method
  class Kernel
    def set_locale *args
      if block_given?
        old = locale

        begin
          __set_locale__ *args
          yield
        ensure
          __set_locale__ old
        end
      else
        __set_locale__ *args
      end
    end
  end

  # using C locale out here

  set_locale( LC_TIME, 'de_DE' ) do
    # do stuff with German locale
  end

  # using C locale out here (again)

> Instead programmers interested in doing I18N / M17N capable ruby 
> and therefore particularly also rails code all around the world
> have to desperately seek ways to implement I18N / M17N.
> 
> That sounds like a tremendous waste of resources because of a
> maybe unlucky decision regarding the frozen locale setting.

Yes, that would be a quite unfortunate case.  But let's wait for
Matz to clarify this situation so we can be sure of the problem.
-- 
Posted via http://www.ruby-forum.com/.