Re: Smoke [blead] v5.27.10-119-g5f6af817ad FAIL(XM) os/390 25.00 (2964/)

[Dave Mitchell]

On Wed, Apr 25, 2018 at 11:31:13AM +, Yaroslav Kuzmin wrote:
> So . I try running bisect.pl
> 
> (16:23) RS12 : PDKUZM | ~/ussport/perl/perl-git
> :> perl Porting/bisect.pl --start 3b6c52ce7d --end 716a866437e -e 'exit 
> (uc("\x{587}") ne "\x{535}\x{552}");'
> This checkout is not clean, found file(s):
> .gitattributes
> 1 modified, untracked, or other file(s)
> These files may not show in git status as they may be ignored.
> Can't run a bisect using a dirty directory containing 
> Porting/bisect-runner.pl.
> That took 1 seconds.
> 
> I can not  remove this file. This file is very important for the system z/OS

Can't you just move .gitattributes to $GIT_DIR/info/attributes
(or whatever the z/OS equivalent is)?

https://git-scm.com/docs/gitattributes

-- 
"You may not work around any technical limitations in the software"
-- Windows Vista license

Re: Smoke [blead] v5.26.0-1591-g56e48c1076 FAIL(XM) os/390 25.00 (2964/)

[Dave Mitchell]

On Thu, Dec 14, 2017 at 06:09:34AM +, Yaroslav Kuzmin wrote:
> No output :

This has me almost completely stumped.

What about the other thing I asked:

> If you do further runs, do you get the same 4 tests consistently failing?

That is, if you run the davem2 script multiple times, do you always get
these same test numbers failing:

$ grep '^not' davem2.py.log
not ok 135890 - isXDIGIT_utf8( \x{B3, MIDDLE DOT}, _safe ) didn't give error
not ok 135891 - isXDIGIT_utf8( \x{B3, MIDDLE DOT}, deprecated unsafe ) didn't 
give error
not ok 135892 - isXDIGIT_LC_utf8( \x{B3, MIDDLE DOT}, _safe ) (C locale) didn't 
give error
not ok 135894 - And got expected message
not ok 135895 - Got a single warning besides
not ok 135896 - isXDIGIT_LC_utf8( \x{B3, MIDDLE DOT}, deprecated unsafe ) (C 
locale) didn't give error

And if not, can you get consistent failures by setting the environment
variable PERL_HASH_SEED=0 ?

-- 
In economics, the exam questions are the same every year.
They just change the answers.

Re: Smoke [blead] v5.26.0-1591-g56e48c1076 FAIL(XM) os/390 25.00 (2964/)

[Dave Mitchell]

On Tue, Dec 12, 2017 at 06:23:47AM +, Yaroslav Kuzmin wrote:
> Log available at 
> https://drive.google.com/file/d/1jGDVWAw-L_ZBZHzfupDKy5uBNRKI9Dm7

Strange. In that run, it is failing four tests. In each case, a string
concatentation is inserting a spurious null character. For example with

$function= "XDIGIT";
$suffix  = "_utf8"; # or "_LC_utf8"
$char= "\x{b3}"; utf8::upgrade($char);
$utf8_param_code = "0";   # or "-1"

"test_is${function}$suffix('$char',";

the result is

"test_isXDIGIT\x{0}_utf8('\x{b3}', 0)"

with similar results for the variants shown in the comments.

If you do further runs, do you get the same 4 tests consistently failing?
Can you run the attached test script and show any output. If should produce
no output normally.

-- 
My Dad used to say 'always fight fire with fire', which is probably why
he got thrown out of the fire brigade.

use Devel::Peek;

sub set_code {  $_[0] = $_[1]; }

$function = "XDIGITx"; chop $function;
for my $n (0..255) {
for $suffix ("_utf8", "_LC_utf8") {
my $char = chr($n);
utf8::upgrade($char);
$char = quotemeta $char if $char eq '\\' || $char eq "'";

$utf8_param_code = "0"; # 1/10 P,IOK
#
$utf8_param_code = 0; my $x = "$utf8_param_code";
study;

my $code;
set_code($code, "test_is${function}$suffix('$char',");
next if $code =~ /^test_isXDIGIT(_LC)?_utf8\('/;
print STDERR "mismatch: n=$n suffix=$suffix\n";
Dump $code;
}
}

Re: Smoke [blead] v5.26.0-1591-g56e48c1076 FAIL(XM) os/390 25.00 (2964/)

[Dave Mitchell]

On Mon, Dec 11, 2017 at 12:52:35PM +, Yaroslav Kuzmin wrote:
> 
> Log availabel at 
> https://drive.google.com/file/d/1BwOR2pbtYRTJ4TqWMh33FtD9PZahf1HM

Unfortunately that run didn't trigger the failure code which has heavy
instrumentation attached. It turns out that there are 5 places in the test
script that do an eval and might fail. The attached davem2 script
instruments all 5 evals.

I would be grateful if you could run it.

-- 
I thought I was wrong once, but I was mistaken.
#!perl -w

BEGIN {
require 'loc_tools.pl';   # Contains locales_enabled() and
  # find_utf8_ctype_locale()
}

use strict;
use Test::More;
use Config;
use Devel::Peek;

use XS::APItest;

# do $_[0] = $_[1]: avoids multiconcat optimising away an assignment
sub set_code {  $_[0] = $_[1]; }

$::TEST_CHUNK = 0;

my $tab = " " x 4;  # Indent subsidiary tests this much

use Unicode::UCD qw(search_invlist prop_invmap prop_invlist);
my ($charname_list, $charname_map, $format, $default) = prop_invmap("Name 
Alias");

sub get_charname($) {
my $cp = shift;

# If there is a an abbreviation for the code point name, use it
my $name_index = search_invlist(\@{$charname_list}, $cp);
if (defined $name_index) {
my $synonyms = $charname_map->[$name_index];
if (ref $synonyms) {
my $pat = qr/: abbreviation/;
my @abbreviations = grep { $_ =~ $pat } @$synonyms;
if (@abbreviations) {
return $abbreviations[0] =~ s/$pat//r;
}
}
}

# Otherwise, use the full name
use charnames ();
return charnames::viacode($cp) // "No name";
}

sub truth($) {  # Converts values so is() works
return (shift) ? 1 : 0;
}

my $base_locale;
my $utf8_locale;
if(locales_enabled('LC_ALL')) {
require POSIX;
$base_locale = POSIX::setlocale( ::LC_ALL, "C");
if (defined $base_locale && $base_locale eq 'C') {
use locale; # make \w work right in non-ASCII lands

# Some locale implementations don't have the 128-255 characters all
# mean nothing.  Skip the locale tests in that situation
for my $u (128 .. 255) {
if (chr(utf8::unicode_to_native($u)) =~ /[[:print:]]/) {
undef $base_locale;
last;
}
}

$utf8_locale = find_utf8_ctype_locale() if $base_locale;
}
}

sub get_display_locale_or_skip($$) {

# Helper function intimately tied to its callers.  It knows the loop
# iterates with a locale of "", meaning don't use locale; $base_locale
# meaning to use a non-UTF-8 locale; and $utf8_locale.
#
# It checks to see if the current test should be skipped or executed,
# returning an empty list for the former, and for the latter:
#   ( 'locale display name',
# bool of is this a UTF-8 locale )
#
# The display name is the empty string if not using locale.  Functions
# with _LC in their name are skipped unless in locale, and functions
# without _LC are executed only outside locale.

my ($locale, $suffix) = @_;

# The test should be skipped if the input is for a non-existent locale
return unless defined $locale;

# Here the input is defined, either a locale name or "".  If the test is
# for not using locales, we want to do the test for non-LC functions,
# and skip it for LC ones.
if ($locale eq "") {
return ("", 0) if $suffix !~ /LC/;
return;
}

# Here the input is for a real locale.  We don't test the non-LC functions
# for locales.
return if $suffix !~ /LC/;

# Here is for a LC function and a real locale.  The base locale is not
# UTF-8.
return (" ($locale locale)", 0) if $locale eq $base_locale;

# The only other possibility is that we have a UTF-8 locale
return (" ($locale)", 1);
}

sub try_malforming($$$)
{
# Determines if the tests for malformed UTF-8 should be done.  When done,
# the .xs code creates malformations by pretending the length is shorter
# than it actually is.  Some things can't be malformed, and sometimes this
# test knows that the current code doesn't look for a malformation under
# various circumstances.

my ($u, $function, $using_locale) = @_;
# $u is unicode code point;

# Single bytes can't be malformed
return 0 if $u < ((ord "A" == 65) ? 128 : 160);

# ASCII doesn't need to ever look beyond the first byte.
return 0 if $function eq "ASCII";

# Nor, on EBCDIC systems, does CNTRL
return 0 if ord "A" != 65 && $function eq "CNTRL";

# No controls above 255, so the code doesn't look at those
return 0 if $u > 255 && $function eq "CNTRL";

# No non-ASCII digits below 256, except if using locales.
return 0 if $u < 256 && ! $using_locale && $function =~ /X?DIGIT/;

return 1;
}

my %properties = (
   # name => 

Re: Smoke [blead] v5.21.11-7-g6b7f14c FAIL(X) os/390 23.00 (2964/)]

[Dave Mitchell]

On Thu, Apr 23, 2015 at 05:15:54AM +, Yaroslav Kuzmin wrote:
 (00:33) RS12 : PDKUZM | ~/ussport/perl/perl-build/t : ./TEST
 uni/parser.t
 t/uni/parser ... # Failed test 52 - RT\# 124216 at ./test.pl line 1039
 #  got 'Malformed UTF-8 character (unexpected non-continuation
 byte 0xb0, immediately after start byte 0x80) at - line 1.
 # Malformed UTF-8 character (1 byte, need 2, after start byte 0xb0) at
 - line 1.'

Thanks, that's given me enough info to fix it (hopefully), with
v5.21.11-12-g1057481.

-- 
You live and learn (although usually you just live).

Re: The remaining os390 core test failures

[Dave Mitchell]

On Wed, Dec 03, 2014 at 04:07:02PM -0700, Karl Williamson wrote:
 I can easily change the test to generate that warning.  But it still isn't
 clear to me whether we are wanting to test line numbers for any regex, or
 just the ??{} ones.  Given the other tests in this file, and that the other
 message is already tested elsewhere, I would think the latter, which is
 where DaveM comes in.

The test is specifically for a ??{foo} included within another regex,
but where the warning is triggered by something in the pattern other than
the foo part, and the warning should appear to to come from the other
part, not the line that defines the ??{foo}.

In other words it's testing that on return from executing the included
foo sub-pattern, that state is correctly restored.

-- 
I don't want to achieve immortality through my work...
I want to achieve it through not dying.
-- Woody Allen

Re: opcode sequence.

[Dave Mitchell]

On Thu, Aug 18, 2005 at 11:19:16PM -0700, rajarshi das wrote:
 Hi,
 Here's a test on perl-5.8.6 run on z/OS :
  
 $a = '0178';
 $b = '00FF';
  
 $a1 = pack(U0U*, hex $a);
 $b1 = pack(U0U*, map { hex } split  , $b);
  
 if (:$b1: =~ /:[$a1]:/i)
 print ok;
  
 The test runs through the opcodes OP_REGCOMP, OP_MATCH and then gets
 into the opcode OP_COND_EXPR. 

Well, the test above should in fact give a syntax error, since that's not
a valid if syntax.

-- 
Britain, Britain, Britain! Discovered by Sir Henry Britain in
sixteen-oh-ten. Sold to Germany a year later for a pfennig and the promise
of a kiss. Destroyed in eighteen thirty-fourty two, and rebuilt a week
later by a man. This we know. Hello. But what of the people of Britain?
Who they? What do? And why?   -- Little Britain

Re: opcode sequence.

[Dave Mitchell]

On Fri, Aug 19, 2005 at 01:15:07AM -0700, rajarshi das wrote:
 cond_expr would be there if there were an else clause.
 But the test doesnot contain an else clause. What I have indicated above is 
 exactly what I run.

I have run it with both sets of values for $a and $b, and both times I see
the next op executed *by the main body of code* to be OP_AND.
Note however, that when the match is exdcuted, match itself calls into
code in utf8_heavy.pl, so the next op executed after the OP_MATCH isn't
the condiition on the next line.

-- 
The Enterprise's efficient long-range scanners detect a temporal vortex
distortion in good time, allowing it to be safely avoided via a minor
course correction.
-- Things That Never Happen in Star Trek #21

Re: Install perl 5.8.4 on os/390 uss with GCC 3.2

[Dave Mitchell]

 Hi perl-mvs 
 Its been a while since anyone commented on installing perl 5.8
 using the Gnu Compiler Collection, GCC 3.2 for USS, provided by David
 Pitts.
 
 I have been somewhat successful using the configure script and
 get as far as a Make Depend.  After a re-edit of the new makefile where
 I remove 37 occurances of 'command line' and ' built-in', I tried
 running the make script, and have some success building 4 .o files.
 
 gv.ominiperlmain.o  perl.o  toke.o
 
 When make tries to build the perly.o file, where I have followed the
 directions in the hints/os390, and am using bison as my yacc, it cannot 
 assemble, and build the load module for perly.o.  I scanned the perl mvs
 news group and google, and found some discussion about this breaking the
 perl build. 
 
 My question is,
 
 
 Is this about as far as one can go, to get perl 5.8.4 built on
 OS/390 USS with GNU GCC 3.2 ???

Hi Gary.
You may be interested to know that in the development branch of
Perl (currently at 5.9.1), the perly.y side of things has been completely
overhauled, in such a way that it no longer requires users on EBCDIC systems
to install bison to build perl itself (I believe it's still needed
to build the s2p binary). However, these changes haven't yet been
integrated back into the 5.8.x branch, since they haven't yet been tested
on an EBCDIC system!

So if you are feeling keen, you might want to try downloading and
installing 5.9.1 (http://www.cpan.org/pub/CPAN/src/perl-5.9.1.tar.gz)
and let us know how you get on.

Dave.

-- 
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.

perly.y and byacc/bison

[Dave Mitchell]

[ Please CC me on any replies as I'm not subscribed here ]

Over on perl5-porters I've put forward a proposal to replace byacc with
bison as the standard tool for generating perly.[ch] from perly.y,
and someone suggested that there may be EBCDIC issues and that I should
ask on this list. Having rummaged around in README.bs2, which
seemed to be the only README that mentioned yacc/bison, I now have the
following questions.

1. Why is the perly.[ch] that is already bunded with Perl not suitable; ie
why do you have regenerate it yourselves?

2. The README file says that the perly.y file should be prefixed with
%pure_parser to generate, well, a pure parser. Is there any particular
reason why this necessary?

3. Would moving the main Perl distribution over to a bison-generated
perly.c help or hinder you, and do you have and gotchas you need to warn
me about?

Thanks,

Dave.

-- 
This is a great day for France!
-- Nixon at Charles De Gaulle's funeral