New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
t/lib/locale.t noisy+complaining but passes on Win32 #13629
Comments
From @bulk88Created by @bulk88t/lib/locale.t is noisy and complaining but passes all tests on Win32. Attaching manual runs at set PERL_DEBUG_FULL_TEST 0,1,2. debug*.txt are Perl Info
|
From @bulk88 |
From @bulk88 |
From @bulk88 |
From @khwilliamsonOn Thu Feb 27 09:48:12 2014, bulk88 wrote:
I am not sure what to do here. It looks like lib/locale.t was originally intended as a hybrid, both a .t to find bugs, and as a diagnostic tool for people to see what's wrong on their system. As such, it always has output messages. I came along and added tests, some of which all but one locale on Windows fail, as Windows has not paid attention to the POSIX standard, whereas Perl code very well may assume that it is running on a system that does. One possibility is to completely turn off the diagnostic capability by default and add documentation (in perllocale) as to how to turn it on. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Wed Mar 05 11:28:16 2014, khw wrote:
Can you explain for the uninitiated (me) how Windows doesn't follow POSIX standard locale wise? Maybe we want our own locale layer (does the term make sense?) instead of using Win32's/MS libc locale layer.
My opinion would be to add note that explains how the system is different from POSIX but this is not a "failure". # 30% of locales pass the following test, so it is likely that the failures # Locale = American I dont see :digit:, I guess d==digit. And what is B2-B3 B9? -- |
From @khwilliamsonOn 03/05/2014 04:41 PM, bulk88 via RT wrote:
All the failures are listed, like the one you have copied below.
That would be hard, and hard to maintain
I think a legend would be good to add to this output. B2 is the code point at 0xB2, and these three code points are The failure that every MS locale has (except C) is to say that a tab is |
From @khwilliamsonOn Wed Mar 05 17:52:12 2014, public@khwilliamson.com wrote:
Actually, I thought about this some more and came up with what might be a solution. The tests that Windows is failing are typically from it having characters be in mutually-exclusive classes. Examples are given below in the quoted text from the previous message about this. My idea is to change the macros in handy.h, like isDIGIT_LC() for Windows only so that they don't say something is a digit which is also punctuation, and that something is also punctuation that is also a control, etc. I did this and Steve Hay, who has a bunch of Windows locales on his machinge, graciously tested this, and after an iteration, got things so no failures were noted. It works by assuming that the Windows :cntrl: definition is correct. Eyeballing seems to show that that is the case. Then it assumes that Windows won't make something punctuation that really isn't (given that it isn't also a control), and it makes sure that something isn't an :alpha: that isn't also an :alnum:, etc. This seems to me to be a good solution, requiring little maintenance going forward and not having to know the details about the Windows locale definitions. But it does change current behavior, so is probably not a candidate for 5.20.
-- |
From @bulk88Testing smoke me khw locale. SHA-1: ffa57b8 * lib/locale.t: Update $variable name C:\p519\srckhw\t>perl -I..\lib harness ../lib/locale.t C:\p519\srckhw\t> with -v to harness ../lib/locale.t .. looks fine now -- |
From @khwilliamsonFixed by commit a5cf558 |
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#121340 (status was 'resolved')
Searchable as RT121340$
The text was updated successfully, but these errors were encountered: