in reply to Strawberry 5.40 Tk affects floating point comma separator

> represented with comma instead of period,

In many countries comma is used as "decimal point". ¹

My first idea would be to check the locale settings of your system.

Also dynamically check/reset inside Perl and Tk, like shown here https://perldoc.perl.org/perllocale#Category-LC_NUMERIC:-Numeric-Formatting

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

updates

¹) since Canada is using both, crossing the street in Montreal might instantly destroy your wealth ;-)

  • Comment on Re: Strawberry 5.40 Tk affects floating point comma separator (perllocale)

Replies are listed 'Best First'.
Re^2: Strawberry 5.40 Tk affects floating point comma separator
by olgo (Sexton) on Jan 02, 2025 at 14:02 UTC

    Indeed, the locale was the problem. Funny thing is that my swedish locale seemed to be ineffective until the call to Tk, which caused it to take effect. Setting locale to english at the start of the program solved it all.

    Thanks for you quick response!

    use POSIX qw(setlocale locale_h LC_ALL); setlocale(LC_NUMERIC, 'en_US.UTF-8');
      > Setting locale to english at the start of the program solved it all.

      If possible, I'd try putting it into a BEGIN block.

      And in case you want it everywhere in Perl, but don't wanna change your system's locale: you can also tweak your Perl installation to do it globally for all programs started.

      > Thanks for you quick response!

      Thanks for the feedback! :)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

        At perlclib Tk is explicitly mentioned. The discussion there and what I'm about to write are more at the C level than the Perl level.

        Every C program, which the Perl interpreter is written in has a set of underlying locale categories. There is a category for the monetary system, another for the decimal point character, and several others. These need not be consistent. I know a person who grew up in the English speaking portion of Canada, now living in Amsterdam, who has his locales set to use Dutch currency, postal addresses, paper sizes, etc, but English as the language, and probably a dot as the decimal point.

        In a pure Perl program, the interpreter performs various locale services for you. One of those is to isolate you from the underlying C locale except when you explicitly say you want to use it, or for a few functions in the POSIX module that are pretty direct pipelines to the underlying C library functions. Windows is not POSIX compliant; I can't remember which of those functions are available in Strawberry, but this is a side note anyway to the main discussion.

        You explicitly tell Perl to use the locale by being in the lexical scope of a 'use locale' statement. Only then do you have to worry about getting a comma versus a dot for the decimal point.

        But when you call any module that isn't also in pure Perl, you are at their mercy for locale handling. Tk is such a module. Until 5.40, the guidance for module authors was not very good. But I undertook to change that by adding extensively to perlclib linked to above. (Patches/improvement suggestions welcome.)

        Earlier than 5.32, I added functions to the Perl C language API with Tk in mind so that a module that is playing around with locales can take control from perl, and when done, return it. Previously both Perl and Tk thought they were the sole masters of locales; the resulting tug of war tended to end badly. I think Tk changed to use these. Newer versions of Tk allow it to not consider itself the master. Maybe doing that would fix your issue. But when a module does have control, Perl can't be doing its normal locale services for you. So you may be exposed to a comma, depending on the locale and module's code

        If you do end up having to set the locale, it is slightly better to use C instead of some English one; that will execute things somewhat faster