[Ardour-Dev] Feedback on string-convert branch

Tim Mayberry mojofunk at gmail.com
Fri Jan 6 05:57:09 PST 2017


On Fri, Jan 6, 2017 at 12:56 AM, Robin Gareus <robin at gareus.org> wrote:

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

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?

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?

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20170106/211e312c/attachment-0002.htm>


More information about the Ardour-Dev mailing list