|
in reply to Re: Avoiding perl's Atof when assigning floating point values
in thread Avoiding perl's Atof when assigning floating point values
I still fail to see "why P5P could not simply adopt this . . . and be done."
Yeah ... maybe I was concentrating more on the reasons that (I believe) they would not, rather than reasons that they could not.
And the bug with windows strtold() turned out to be far less significant than I thought it would be.
Its looking like __mingw_strtold should be an alias for strtold (just as __mingw_strtod is an alias for strtod), but for some reason (probably oversight), that's not happening.
In any case, the patch that handles this bug does so as efficiently as would fixing the bug in the mingw-w64 port of gcc.
I just can't see p5p adopting this patch simply on the basis of the testing that I've done - though I'll probably raise it with them again once I've managed to properly prepare myself for the eventuality of being ignored once more. (Not a particularly pleasurable experience.)
Cheers,
Rob
|
Re^3: Avoiding perl's Atof when assigning floating point values
by syphilis (Archbishop) on Jul 28, 2018 at 12:27 UTC
|
I just can't see p5p adopting this patch simply on the basis of the testing that I've done
The good news is that there has been some more testing done.
Karl Williamson and Jim Keenan created smoke-me branches to specifically test my changes (at http://perl.develop-help.com/?b=smoke-me%2Fkhw-sisyphus and http://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2Fsisyphus%2F41202-2nd-text-float respectively). Many thanks to Karl and Jim for doing that.
The bad news is that the results aren't great. The one smoker (Carlos Guevara's) that has tested those branches has frequently encountered lib/locale.t test failures.
It has also encountered other problems, such as ticket #133356 and ticket #133377, but they are separate issues not related to my changes - and I've no need to concern myself with them for now.
OTOH, the lib/locale.t failures seems to have arisen from the changes I've made, and that's the issue I need to address.
Unfortunately, I can't reproduce those failures locally - and I'm hoping that someone here might be able to help out.
The source for Karl Williamson's branch is here. I would love to enter into a dialog with anyone who can download that file, unpack it, and build from it (on a Unix-type system) a perl that fails any lib/locale.t tests. (I have questions regarding the %Config and locale settings for such a perl).
Having unpacked the source, cd to the top level folder and run:
sh Configure -des -Dusedevel -Duse64bitall && make && make test
Examining the individual reports for Karl's branch, I can see that the lib/locale.t failures that I'm interested in are occurring on all of Carlos's FreeBSD and NetBSD systems (but not his OpenBSD system), on his Solaris system, on his slackware system, on his Fedora systems, and on his Ubuntu-14.04 (but not 16.04 or 18.04) system.
I have 2 things to say to anyone who can help me out with this:
1) thank you ever so much;
2) get a life ;-)
Cheers,
Rob | [reply]
[d/l]
[select] |
|
|
lib/locale ..................................................... FAILE
+D at test 427
lib/locale_threads ............................................. skipp
+ed
I'm running Debian 9.4; my locale is ru_RU.UTF-8. The failures might be related to the fact the my locale (like some European ones) uses a comma (,) as decimal separator1, unlike a dot (.) as expected by "C" locale: https://paste.debian.net/1035555/ (a PM post doesn't seem to be enough for this log).
Here is my %Config, as obtained by cd t; ./perl -I../lib -MData::Dumper -MConfig -e'print Dumper \%Config':
Is there anything else I could send you?
1Yes, it has bitten me in the past when I wrote a library to talk to a device using standard C string formatting functions, then something else in the process called setlocale(LC_ALL, "") and everything got broken. | [reply]
[d/l]
[select] |
|
|
UPDATE: Since writing this post, I've managed to reproduce the lib/locale.t failure on my Ubuntu-16.04 box by switching locale to LANG=de_DE.UTF-8.
I now just need to make sense of what I'm seeing.
The failures might be related to the fact the my locale (like some European ones) uses a comma (,) as decimal separator, unlike a dot (.) as expected by "C" locale
Then I wonder if I might be able to strike the same issues on my Ubuntu-16.04 box by messing with its locale settings. I'll have to at least give that a try.
I've no experience with messing with locale settings - but I expect that google has lots of advice to offer on how to do this.
I'm sure that my patches affect only the values that are assigned - they change nothing about the way that values are displayed.
If C's strtod() doesn't honor the locale when parsing the input string, then that would cause breakage. However, in such a case I would expect more extensive breakage than just a lib/locale.t failure.
And, of course, such a perl would have no business in defining Perl_strtod in the first place - and the default that allows the defining of $Config{d_strtod} ought to be changed.
Could you test one more thing for me, please ?
When (if) you have the time, could you rebuild that source with the addition of -Ud_strtod to the configure args. That is:
make distclean
sh Configure -des -Dusedevel -Duse64bitall -Ud_strtod && make && make
+test
I'm hopeful that will allow the lib/locale.t tests to pass without introducing more breakage elsewhere.
Thank you very much for the trouble you've taken and the information you've provided.
Cheers,
Rob | [reply]
[d/l]
[select] |
|
|
|
|
| |
|
|
|
|
|
|
|
