<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 6, 2017 at 12:56 AM, Robin Gareus <span dir="ltr"><<a href="mailto:robin@gareus.org" target="_blank">robin@gareus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_1702536067338797804HOEnZb"><div class="m_1702536067338797804h5">On 01/05/2017 03:36 PM, Robin Gareus wrote:<br>
> On 01/05/2017 12:12 AM, Tim Mayberry wrote:<br>
>> On Thu, Jan 5, 2017 at 7:14 AM, Paul Davis <<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>><br>
>> wrote:<br>
>><br>
>>><br>
>>><br>
>>> On Wed, Jan 4, 2017 at 12:52 PM, Tim Mayberry <<a href="mailto:mojofunk@gmail.com" target="_blank">mojofunk@gmail.com</a>> wrote:<br>
>>><br>
>>>> I've pushed a branch called string-convert to the main repository that<br>
>>>> I'd like<br>
>>>> some feedback on from the other developers when they get a chance. It<br>
>>>> represents a fair bit of work over the last year or so and is attempt to<br>
>>>> make<br>
>>>> improvements to the de/serialization code in Ardour.<br>
>>>><br>
>>><br>
>>> I still don't understand how this is supposed to work with plugin data. If<br>
>>> you leave the global locale setting untouched, how do we know what to do<br>
>>> when reloading plugin data across two systems where the global locale may<br>
>>> be different?<br>
>>><br>
>>><br>
>><br>
>> Of the 100 or so LocaleGuard's in master, the 10 or so that remain are in<br>
>> the Plugin get/set_state methods, which is why I mentioned removing<br>
>> LocaleGuard's that guard internal string conversion.<br>
><br>
> Since changing the locale is expensive, so we should also retain a<br>
> single LocaleGuard in save_state() rather than switch forth/back in<br>
> every Plugin get/set state.<br>
><br>
> With some luck, plugins don't change the locale and every save only<br>
> needs to change the locale once.<br>
><br>
><br>
>> That some plugins depend on a specific global locale for correct operation<br>
>> or worse modify the global locale is dissappointing but seems to be a<br>
>> reality and it is accounted for in the branch.<br>
><br>
> ..and it's worse. Some plugins expect to also *run* in the "C" or en_US<br>
> locale. e.g. NI Kontakt fails in numeric-locales that use a comma, and<br>
> NI isn't alone.<br>
><br>
><br>
> If we add a custom system, I think it's better to<br>
><br>
>  - don't change the locale at all, keep using the default "C" locale for<br>
> C++/std::locale<br>
><br>
>  - keep relying on standard functions for string-conversion<br>
><br>
> and instead<br>
><br>
>  - come up with a custom message-translation system that does not depend<br>
> on the std::locale at the time the message is formatted.<br>
><br>
<br>
</div></div>PS. The recent code to only set LC_MESSAGES is step in that direction.<br>
<br>
For now the intention is to investigate and to collect feedback from<br>
various affected systems + plugins.<br>
<br>
<br>
@Tim: can that code that you wrote also work in the other direction?<br>
Can we use it to format floats with some preferred user's locale (comma,<br>
dot) for display only?<br>
<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">No it can't, that is totally contradictory to the API design as numeric formatting is intended to be independent of locale.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We already use API's that do that as you know, but I'm guessing you are referring to functions where you are explicitly passing a locale_t or std::locale and are independent of the global locale?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I mentioned a few of those in the original email but we can't use them atm and so we would have to write them....but I'm not sure I see the point?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Tim</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>