Front page | perl.perl5.porters |
Postings from February 2014
So this means it doesn't mater if you have a user base doing production work with it and what processes will potentially break. Soon as this is not supported many shops will have no choice but to rewrite stuff to remove perl from our systems. Lack of support in the main stream pretty much mean end of life of the product. I have no idea what your actually needing. I have access to a system but can I promise it will always be available only if I could promise I'll always have the same position which in IT isn't always gold Sandra From: Karl Williamson <public@khwilliamson.com> To: Brad Gilbert <b2gills@gmail.com>, "Konovalov, Vadim" <Vadim.Konovalov@emc.com> Cc: Ricardo Signes <perl.p5p@rjbs.manxome.org>, "perl5-porters@perl.org" <perl5-porters@perl.org>, "perl-mvs@perl.org" <perl-mvs@perl.org> Date: 02/20/2014 01:08 PM Subject: Re: EBCDIC support is on the chopping block On 02/20/2014 08:29 AM, Brad Gilbert wrote: > On Wed, Feb 19, 2014 at 11:43 PM, Konovalov, Vadim > <Vadim.Konovalov@emc.com> wrote: >>> From: Karl Williamson [mailto:public@khwilliamson.com] >>> But as it turns out, I agree with him. Unless we can get a regular smoke >>> facility, there's no point in trying to support EBCDIC. >> >> Indeed. >> >> from technical POV - this support UTF-EBCDIC - while it obviously costs some >> maintenance efforts - does it cost any CPU speed for non-EBCDICs? >> > > We are only talking of removing official support for it. > > That doesn't mean that any of the code will be ripped out immediately. > Although I wouldn't bet on it staying in for long. > > Really once it is removed, it would be easier to see ways of improving the code; > so it is possible that it does cost CPU speed in ways we can't yet see. > I can't think of any performance penalties for having EBCDIC that aren't negligible. There are known optimizations that haven't been applied, but these could be enhanced to also work for EBCDIC, or be #ifdef'd.Thread Previous | Thread Next