[vtkusers] [Insight-developers] wx/vtk weirdness

[Bill Lorensen]

Tom,

I don't think we need to be concerned with the per-thread issue. My
changes are all local to the methods that need c-locale's. For
example, surrounding the ReadImageInformation calls with save/restore
locales in many readers fixes the readers.

Maybe you can try my simple itkLocale class. I'll send it in a separate mail.

Bill

On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Tom,
>
> What I have done is create an itk class, itkLocale, that in its
> constructor saves the current c-locale and creates a new one. The
> destructor restores the original locale.
>
> C++-locales are handled explicitly with imbue.
>
> I'll try your approach in the itkLocale class.
>
> BTW, I have not checked in any code yet.
>
> I think it is time to start an ITK Policy and Procedure page for
> internationalization on the itk wiki.
>
> It can include the work you are doing with unicode.
>
> I'll give it a stab today. Then we can start a new thread on itk developers.
>
> Bill
>
>
> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
> <tom.vercauteren at gmail.com> wrote:
>> Hi Bill,
>>
>> I would just like to mention that in our group we have been facing
>> several issues with locale support on mac.
>>
>> Looking at the documentation of xlocale:
>>  http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>> you will see that setlocale will have absolutely no effect (on mac,
>> maybe on windows also
>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>> per-thread locale had been specified.
>>
>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>>  http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>>  http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>>  http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>>  http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>
>>
>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>> chose to proceed:
>>
>> // Create a new locale based on a copy of the current one (which need
>> not be explicitly set)
>> // but where LC_NUMERIC has been modified to match the C locale
>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>> // Use this new locale and store the current one to reset it aftwards
>> locale_t previousLocale = uselocale(templocale);
>>
>> [Actual useful code]
>>
>> // Reset the locale to the previous one
>> uselocale(previousLocale)
>> // More house keeing
>> freelocale(tempLocale)
>>
>>
>> Actually, on mac we also had to do explicitly create thread-specific
>> locale to avoid some random crash in heavily threaded code. But that
>> is a slightly different topic
>>
>> Cheers,
>> Tom
>>
>>
>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> I've already made a pass through the itk readers. Several were broken
>>> wrt locale.
>>>
>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>> locale in and itk::Locale class.
>>>
>>> I have not checked in any changes yet, but I went from over 40 failing
>>> I/O tests down to 0.
>>>
>>> Bill
>>>
>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>> Luis,
>>>>>
>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>> any changes yet. Still more investigation is needed as to the best
>>>>> portable solution.
>>>>>
>>>>> I do this:
>>>>>   const char *originalLocale;
>>>>>   char *currentLocale;
>>>>>   originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>>   currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>>   setlocale(LC_NUMERIC, "C");
>>>>>
>>>>> ......
>>>>>
>>>>>
>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>>         free(currentLocale);
>>>>
>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>
>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>
>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>> snippets.
>>>>>
>>>>> There are other readers/writers that use C++ streams, and there we
>>>>> will have to imbue.
>>>>
>>>> I think that using the C locale is probably the easiest short term solution,
>>>> but to support GUIs using different locales we should be using the C++ locale
>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>> subtle bugs if reading and writing files in separate threads that are all
>>>> using C locales.
>>>>>
>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>> etc. In the long run we probably should address these cases with
>>>>> stream replacements.
>>>>
>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>> existing code with C++ streams. As you say this should probably be part of a
>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>> to our libraries.
>>>>
>>>> Marcus
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>
>