Front page | perl.perl5.porters |
Postings from January 2010
Jan Dubois wrote: > On Mon, 18 Jan 2010, Karl Williamson wrote: >> Nicholas Clark wrote: >>> [snip] >>> >>> (The answer to the obvious next question is "no" - there isn't a defined way >>> to feed the changes back. And I might be stating the obvious, but changes need >>> to work on Perl versions as far back as Unicode::Normalize currently supports) >> I planned to deliver the official Unicode (current version 5.2) >> NormalizationTest.txt file into lib/unicore, where all the other >> official Unicode consortium files are. I then planned to deliver >> somewhere the .t file I have written that reads NormalizationTest.txt as >> input and converts all its tests to TAP style. >> >> There would be no code changes involved to the current Normalize >> package. But if this were to be added to that package, it would break >> things on older Perls, since they don't have the respective >> NormalizationTest.txt file for the version of Unicode they are shipped >> with. And including the 5.2 .txt file wouldn't work as it is different >> for each Unicode version. >> >> Thus this test couldn't be part of Unicode::Normalize, but would be >> something that is added to MANIFEST and would be run as part of 'make test'. >> >> Correct me if I'm wrong. > > I think it is perfectly acceptable that the test will simply be skipped > if it cannot find the NormalizationTest.txt file. > > Cheers, > -Jan > OK, thanks. But as I prepare this for submittal, I wonder if it takes too much CPU time. It runs 360K tests and takes 3.5 minutes on my almost-a-year-old (hence pretty fast) PC. One solution would be to run a random selection of tests each time with an option to run all. About 20 tests are run currently for each code point, so we would run at least one per code point in a reasonable amount of time. That would have found the bug that spurred this. How should I proceed?Thread Previous | Thread Next