develooper Front page | perl.perl5.porters | Postings from September 2011

Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT in afuture release of Perl

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
September 26, 2011 09:45
Subject:
Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT in afuture release of Perl
Message ID:
20110926164528.GD23881@plum.flirble.org
> -----Original Message-----
> From: jhi@iki.fi [mailto:jhietaniemi@gmail.com] On Behalf Of Jarkko Hietaniemi
> Sent: Monday, September 26, 2011 12:11 PM
> To: jhi@iki.fi
> Cc: Jesse Vincent; John Goodyear; Craig A. Berry; perl-mvs@perl.org; Perl5 Porters
> Subject: Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT in a future release of Perl
> 
> >
> > Executive summary: some current users of the Perl on z/OS need to step 
> > up, and do the porting/support, or it will not happen.
> 
> I haven't seen the beginning of the discussion: is the plan to remove #ifdef EBCDIC etc. code?  Is it such a maintenance burden?  I thought it was reasonably well contained.

The "discussion" as such starts here

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg01041.html

where Tom Christiansen asks "Do we have any proof that current versions of
Perl actually *work* EBCDIC platforms?" noting that perlebcdic manpage says

    Perl used to work on EBCDIC machines, but there are now
    areas of the code where it doesn't.  If you want to use
    Perl on an EBCDIC machine, please let us know by sending
    mail to perlbug@perl.org


My reply was:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg01043.html

  To my knowledge, no proof whatsoever.
  
  I think that we should announce with 5.16 that in 5.20 we will be removing
  the EBCDIC support code, and see who squeals.
  
  (and what colour their money is)

Karl's reply was

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg01048.html

  I was the one who added that text to the manpage.  I did it because
  there are places in the code where it clearly doesn't work with
  EBCDIC.  I have cleaned up a number of those areas in 5.14.  But
  there remain others.  For example, in regexec.c, when it loads a
  Unicode table, it checks that a hard-coded utf8-encoded string
  matches.  It is not a utf-EBCDIC string, and therefore may or may
  not match.


What I didn't say is that some things I'd added have been considerably more
complex because I've tried not to make ASCII assumptions. And that I'm put
off working on something else, because

a: It would need a different code path for UTF-EBCDIC
b: I have *NO WAY OF TESTING THIS*

So do I

a: add breakage by adding #error this part left as an exercise to the reader

or

b: add breakage by guessing, and writing something that doesn't work properly

[I'm not good enough to write C "blind" and get it right]

Both alternatives suck.


It's a pain thinking that we need to support EBCDIC, and taking a cost hit
for that, when Karl is confident that as-is

a: for current EBCDIC can't still be working
b: no-one has reported this

On Mon, Sep 26, 2011 at 04:13:32PM +0000, Peter Prymmer wrote:
> Doesn't taking it out represent more (potentially risky) work?
> What would satisfy this request?  A patch to a hints file?

Yes, taking it out has a cost, with a risk. Leaving it in has a cost too,
as it makes the existing code harder to follow. Long term, if no-one is
going to put the effort into keeping blead working on EBCDIC, the up-front
cost of taking the code out will soon pay off.

By "What would satisfy this request?" do you mean "what needs to be done
to avoid the decision being taken to remove the EBCDIC code from blead?"

I think, initially:

0: Build report for current blead on EBCDIC
   Assuming that it fails to build, also ascertain
1: at what point did *building* for EBCDIC fail (preferably to the commit.
   git bisect should be able to locate this with 15 or fewer test points)
2: at what earlier point do tests start failing on EBCDIC?

but that's only going to defer a decision.

Medium term, I think what's needed is to get blead building again on EBCDIC,
which means someone working out what needs patching, and working with the
committers to get those patches into a sane state to apply.

Then get failing tests to pass, and fixes merged in.

Long term, really what's needed are

1: some sort of smoke server. Win32 smoke servers have helped massively in
   avoiding inadvertent breakage on Win32. Craig Berry generates
   moderately frequent smoke reports for VMS, and I believe is working
   on automating it.
2: someone "around" with enough EBCDIC knowledge able to answer questions/
   fix things when non-EBCDIC users inadvertently break EBCDIC building.

Without reaching something like this, longer term, the steady state of
EBCDIC is going to be "broken", which benefits no-one.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About