Re: Status of z/OS perl5 port

2015-10-25 Thread Jarkko Hietaniemi

On Thursday-201510-22 19:04, Karl Williamson wrote:

SUMMARY

Core blead perl works quite well on z/OS.  That isn't necessarily true
of the cpan modules whose primary maintainers aren't perl5 porters, but
which are packaged with the core, although the vast majority do work.  I
plan to now work on some of those, depending on time and energy.  This
is your chance to nominate ones for me to prioritize.


Congrats, and thanks!

I fully approve of getting Perl running on "unusual" platforms.

Kind of like, you know, perl5-*porters*.





Status of z/OS perl5 port

2015-10-22 Thread Karl Williamson

SUMMARY

Core blead perl works quite well on z/OS.  That isn't necessarily true 
of the cpan modules whose primary maintainers aren't perl5 porters, but 
which are packaged with the core, although the vast majority do work.  I 
plan to now work on some of those, depending on time and energy.  This 
is your chance to nominate ones for me to prioritize.


DETAILS

The latest z/OS smoke report again shows 0 failing tests.  The last time 
this happened was about the time Perl 5.22 shipped in early June.  At 
about that time, Yaroslav discovered that some test files had not been 
getting run, and now running those introduced about 10 failures.  It 
turns out that all of those faiures were problems in the tests and not 
the core implementation, and are now fixed.


I have now done an audit, and can confirm that there are no additional 
test files that are being skipped inadvertently.


I also did another audit to see if there were tests being deliberately 
skipped on EBCDIC platforms that could now be run.  These would be 
leftovers from earlier perl versions, like 5.8, when EBCDIC last was 
known to work.  Running the ones found introduced yet more failures, and 
all turned out to be issues with the test itself.  This means that perl 
works better than it ever did on EBCDIC platforms.


During the code freeze before 5.22, I became aware of 2 core bugs with 
EBCDIC, and for which no tests had been written.  These involved tr/// 
and string comparisons with both operands being UTF-EBCDIC encoded, such 
as in sorting and the 'lt' and 'ge' operators.  Those are now fixed.


Also, in 5.22, there were tests in two .t files that I skipped because I 
had given up getting those fixed in 5.22.  One of those is dependent on 
one of the cpan modules that hasn't been fully ported to run on EBCDIC 
systems, Encode.  The other turned out to be a problem in the test 
itself, now fixed.


In the past few months, I made a number of changes to the base handling 
of EBCDIC for efficiency and to clean some things up.  I introduced some 
bugs in the process, but after some iterations, these appear to be gone.


The tests that aren't run are almost entirely the cpan modules.  Only a 
few cpan ones are now actually getting run.  This is in part because 
Yaroslav's machine takes about half a week to get through them all, so 
as some of the modules have gotten fixed, I've removed them from being 
smoked.  I'll do another look through the core tests that skip on z/OS 
and/or EBCDIC.  This may lead to some more temporary failing tests.  The 
few skips in the core tests are due to 1) I haven't noticed them before; 
2) the ones dependent on Encode; 3) one involving CBuilder that I have 
asked for help with <562869ce.8030...@khwilliamson.com>; 4) ones that 
are very closely tied to ASCII and for which it would be too much effort 
(IMO) to get working for non-ASCII.  An example of this is a published 
test suite for malformed-UTF8.  These malformations do not easily 
translate into EBCDIC.


My plan now is to get Encode working, and then to run a test of the full 
suite, including everything we package from cpan.  A bunch of things 
depend on Encode, and other modules that now have fixes in them since 
the last time we ran the full suite.  At that time the pass rate was 
somewhere in the low 90's%.  By getting these dependencies fixed, we'll 
see what really remains.