Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^2: weird problem with macports perl on apple m1/m2 based system

by perltux (Monk)
on Jun 10, 2023 at 22:10 UTC ( [id://11152754] : note . print w/replies, xml ) Need Help??


in reply to Re: weird problem with macports perl on apple m1/m2 based system
in thread weird problem with macports perl on apple m1/m2 based system

would it help if I add 'no integer;' ad the beginning of the program?

My problem is I don't actually own a M1 or M2 Mac myself (to be precise I don't own any Mac at all), this problem got reported to me by a user who runs my program on a M1 Mac, and he is the one who tests the code I give him and then reports back the output he gets.
Now that after some back and forth I finally managed to narrow down the issue to those lines of code posted in the first post I'd prefer not to bother him again straight-away with more questions and tests, I don't want to strain his willingness to help too much.

That's why I was hoping that someone here with a M1/M2 Mac and good Perl knowledge could look into this a bit.

If it helps, these are the instructions my user followed to install MacPorts Perl on his M1 MacBook:
http://obd-amigos.linuxtech.net/files/00-How_to_install_OBD_Amigos_on_macOS.html

Replies are listed 'Best First'.
Re^3: weird problem with macports perl on apple m1/m2 based system
by hv (Prior) on Jun 11, 2023 at 00:15 UTC

    would it help if I add 'no integer;' at the beginning of the program?

    I generally would not recommend making random changes - I would always rather actually understand the root cause of the problem first. You can at least do tests on your own system to see if, for example, setting environment variables allows you to replicate the behaviour that the user has reported.

    I misspoke in my previous message: the environment variable I was thinking of is actually PERL5OPT. So here I see, for example:

    % perl -wle 'print 3.9 * 3.9' 15.21 % export PERL5OPT='-Minteger' % perl -wle 'print 3.9 * 3.9' 9 % export PERL5OPT='-Mbigint' zen2% perl -wle 'print 3.9 * 3.9' 9 % export PERL5OPT='' % perl -wle 'print 3.9 * 3.9' 15.21 %

    If such tests give behaviour that matches what your user reports, then it would be reasonable a) to report the contents of that environment variable at startup, and optionally b) to clear it. But don't get me wrong - I don't think it is highly likely that a strange setting of PERL5OPT is the cause, it's just one of the few things I can think of that could affect something as fundamental as Perl's arithmetic if the perl build is otherwise functional.

    I don't have a Mac, but I think it is relatively unlikely that there is so fundamental a problem on all Macs of this sort; it is more likely something specific to the environment (in the general sense) of this user's system.

      Ok, if I add 'use integer;' or 'use bigint;' (in both cases the behavior here is the same) to the test script and then run it on my Intel PC with Linux, I get the following output:
      12.00 16.00 192

      While the Mac M1 user gets:
      12.99 16.25 192

      Basically on the Mac M1 only in the last 'eval' (the one with the multiplication of the previous two values) the decimals get ignored, they don't get ignored everywhere and that's what makes this problem so strange, if he had some env setting that forces integer then all values would be integer like in my test that I just did with 'use integer;'.

      I don't think it's a fundamental Mac M1 problem either, but I'm suspecting that maybe Perl and/or the Perl-Tk module from MacPorts for the M1 cpu have been compiled with some incorrect flags that cause this behaviour.

      That's why I was hoping that maybe somebody else here can reproduce the issue on a M1 or M2 Mac with the test script.

        If any ideas are welcome: locale is somehow active and sprintf produces strings $x and $y with comma as decimal point, then eval('$x * $y') would give 192 (and warnings ignored by user).