develooper Front page | perl.perl5.porters | Postings from October 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:
October 3, 2011 02:04
Subject:
Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT in afuture release of Perl
Message ID:
20111003090352.GB23881@plum.flirble.org
On Mon, Oct 03, 2011 at 01:45:43AM -0400, Eric Brine wrote:
> On Fri, Sep 30, 2011 at 3:05 PM, Karl Williamson <public@khwilliamson.com>wrote:
> 
> > It is my understanding that more modern Perls will compile and run when the
> > locale is utf8.  We also have Encode available to translate EBCDIC data to
> > Unicode on input, and back on output.
> >
> 
> So if we removed all internal support for EBCDIC and UTF-EBCDIC, EBCDIC
> users are left in the same situation as cp1252 and UTF-8 users (the need to
> encode outputs and decode inputs), except for the inability to read source
> files. That ability can be added by having the parser automatically decode
> source files from EBCDIC (as it does for UTF-8 files under "use utf8;") on
> that platform.
> 
> Unless I am missing something, this would make it easy to re-add EBCDIC
> support.

a: I think that you're missing the possibility of EBCDIC users having XS
   code that interfaces to local C libraries that are assuming EBCDIC

b: My hunch is that
   i)  Craig is right - if all the EBCDIC related code were removed in one
       (or few) clearly labeled the tools associated with git would make it
       fairly easy to track where it should be added back in (even if it
       doesn't automatically apply)
   ii) that won't make it easy to make things *work*.

   but that in terms of total effort, it won't be much different because
   *all* the existing EBCDIC code is suspect, and will have to be reviewed,
   because in recent years some chunks of it will have been edited "in good
   faith" on non-EBCDIC systems, without ever being tested on an EBCDIC
   platform.

   Hence it has to be reviewed, whether it's being added back, or whether
   it stayed in.



and I then feel the urge to restate this:


Without an ongoing facility on which to regularly test the development
version of perl, breakages are going to slowly accumulate. This will happen
even if the people making the changes to the perl core are thinking of
EBCDIC, and trying not to break it.

[Consider what happens at the moment with Win32 and VMS, which are regularly
tested. There are still lots of small test breakages, because most people
are developing on some flavour of Unix, and don't even realise that they
have made a portability error. These get fixed fairly quickly, because "we"
know about them, and some of "us" have access to the relevant platforms,
understand them well enough, and personally have reason to care about them
still working. Which means that future changes don't come to rely on the
wrongness.]

So what's needed are

1) a testing facility just to stand still.

2) the pool of active core developers expands to include people who care
   about keeping perl on EBCDIC working.

The existing core developers ("the community") is not able to provide either
of the above. It seems that IBM isn't able to provide either of the above.

HP do not make such a mistake with VMS - they provide access to OpenVMS
systems to facilitate open source porting.

Just for once, HP is doing something right. :-) IBM should learn from HP.

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