On Thu, 29 Mar 2001 [EMAIL PROTECTED] wrote:
> >I think the fact that open($fh,":utf8",...) produces UTF-EBCDIC is
> >confusing, could we at least have an exlplicit open($fh,":utfebcdic",...)?
>
> Well 'use utf8' is the same ;-)
> Making the name conditional in perlio.c is trivial, but I am worried
> that we are just making a port-ability issue out of nothing.
>
> Rather than
>
> use utf8;
>
> One has to have
>
> BEGIN {
> if (ord('A') == 193) {
> require utfebcdic;
> import utfebcdic;
> }
> else {
> require utf8;
> import utf8;
> }
> }
>
> And UTF-EBCDIC is _a_ UTF "8" - it is 8-bit and is UTF. It just isn't UTF-8.
That is the problem I think: it is not UTF-8 and documentation that
mentions that encoding form could be construed as misleading for EBCDIC
platforms. I'll take a look through the current pods to see...
> >> TI's mainframe has very bare /etc/* and getprotobyname() et. al.
> >> don't work. Could do with testing ...
> >
> >On OS/390 R2.10 I just obtained:
> >
> >lib/io_multihomed.....ok
> >lib/io_sock...........ok
> >lib/io_udp............ok
>
> Much better.
>
> >lib/io_unix...........Can't call method "getline" on an undefined value at
> >lib/io_unix.t line 65.
> >FAILED at test 3
> >
> >
> >lib/xs-typemap........ok
> >
> >with a default statically linked build of perl@9424 (?)
>
> Good - the snapshot has a fixed version of XS test then :-)
>
> >>
> >> use warnings 'once' report is stash key order, that is different
> >> when $x and $z have EBCDIC x and z.
>
> If you can work out how to do that given structure of warnings.t
> go ahead ;-)
>
> >
> >One might suspect that sorting expected and returned results on EBCDIC
> >machines might help here - for some reason I thought that there was more
> >to it than that though.
> >
> >Here is my summary:
> >
> >comp/require..........FAILED at test 21
> >op/append.............FAILED at test 7
> >op/bop................FAILED at test 36
> >op/pat................FAILED at test 234
> >op/tr.................FAILED at test 50
> >op/vec................FAILED at test 27
> >op/ver................FAILED at test 19
> >pragma/locale.........FAILED at test 99
> >op/taint..............ok
> >no warnings 'once' ;
> >FAILED at test 73
> >lib/charnames.........FAILED at test 4
> >lib/digest............FAILED at test 1
> >lib/glob-basic........FAILED at test 10
> >lib/io_unix...........Can't call method "getline" on an undefined value at
> >lib/io_unix.t line 65.
> >FAILED at test 3
> >lib/md5-file..........FAILED at test 1
> >lib/mimeqp............FAILED at test 2
> >
> >camel-III/vstring.....ok
> >Failed 15 test scripts out of 320, 95.31% okay.
> >u=17.91 s=5.97 cu=399.63 cs=133.21 scripts=320 tests=23049
>
> ./perl harness rather than 'make test' is much more interesting when
> there are fails.
Will do.
> >just checking the wall clock time (as opposed to running under `time make
> >test`) it seems that the heap allocation speeds things up _tremendously_
> >(enough such that we ought to consider changing miniperl.c in
> >5.6.1-trial3).
>
> I didn't change the initial allocation (or not by much) - that
> may be worth tuning.
As a follow up to this issue, I tested 5.6.1-trial3 with and without
that allocation in miniperlmain.c and the results, including failure rate
and time to completion were roughly the same with or without the
allocation patch applied. The speed up that I thought I saw yesterday was
due to me working in a fast tmpfs on a 2.10 LPAR yesterday that I had not
used for test building before (recall that last week I was complaining
about disk space churning on our machine - this was fallout).
Peter Prymmer
