<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 6, 2017 at 12:36 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"><span>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>
</span>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>
<span><br></span></blockquote><div> </div><div>And then remove all the other obvious LocaleGuards in the Session state call tree? That is an option for that particular issue I guess.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<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>
</span>..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></blockquote><div><br></div><div>I'm not sure I understand, this is how it is currently and does not really address any of the issues I raised, so I'd be interested in hearing why you think it is better than what I have proposed.</div><div><br></div><div>If you keep the current method of serialization, you would still need to identify and individually fix the many incorrect numeric conversions that I have fixed in the branch (which may not be too hard as I had to find/audit them and most are mentioned in the commit log AFAIR) but that really only fixes the current issues with round trip equality. It doesn't address the other issues and it doesn't help to reduce incorrect serialization in the future. Part of the intent with changing the API's rather than just fixing all the individual issues is to fix it once and in the future all serialization is correct by default/automatically.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>I'm not sure what you mean here either. Are you referring to message translation i.e gettext or numeric conversion via snprintf/sscanf/iostream/etc?</div><div><br></div><div>Tim</div></div></div></div>