RFC: Remove support for Ultrix?

There is some complicated code for Ultrix in locale.c that I've never 
been comfortable with.  Now I find that the last release of this OS was 
in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmari 
checked that)

I added this comment some years ago

/* XXX This is to preserve old behavior for Ultrix
  * when i==0, but I (khw) don't think that behavior makes much
  * sense */


I'd like to get rid of that, and from having to spend time on 
considering this special case when working with this file.

I'm thinking we don't need to keep up support for this OS any longer.
0
public
3/13/2018 6:05:36 PM
perl.perl5.porters 47200 articles. 0 followers. Follow

6 Replies
53 Views

Similar Articles

[PageSpeed] 6

On Tue, Mar 13 2018, Karl Williamson jotted:

> There is some complicated code for Ultrix in locale.c that I've never
> been comfortable with.  Now I find that the last release of this OS
> was in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmari
> checked that)
>
> I added this comment some years ago
>
> /* XXX This is to preserve old behavior for Ultrix
>  * when i==0, but I (khw) don't think that behavior makes much
>  * sense */
>
>
> I'd like to get rid of that, and from having to spend time on
> considering this special case when working with this file.
>
> I'm thinking we don't need to keep up support for this OS any longer.

I agree, FWIW it's useful to sanity check these sorts of things against
some other highly portable thing, like git, which has never been ported
to ULTRIX, but does run on these currently:
    
    git.git $ grep ifeq.*uname_S config.mak.uname |grep -P -o '(?<=,)[^)]+'|sort
    AIX
    Darwin
    FreeBSD
    GNU
    GNU/kFreeBSD
    HP-UX
    Interix
    IRIX
    IRIX64
    Linux
    Minix
    MirBSD
    NetBSD
    NONSTOP_KERNEL
    OpenBSD
    OSF1
    QNX
    SCO_SV
    SunOS
    UnixWare
    Windows
0
avarab
3/14/2018 5:32:10 PM
---1454121964-725701337-1521054499=:20044
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

From the keyboard of Karl Williamson [13.03.18,12:05]:

> There is some complicated code for Ultrix in locale.c that I've never been 
> comfortable with.  Now I find that the last release of this OS was in 1995, 
> and the last post in comp.lang.ultrix was in 2013 (ilmari checked that)
>
> I added this comment some years ago
>
> /* XXX This is to preserve old behavior for Ultrix
> * when i==0, but I (khw) don't think that behavior makes much
> * sense */
>
>
> I'd like to get rid of that, and from having to spend time on considering 
> this special case when working with this file.
>
> I'm thinking we don't need to keep up support for this OS any longer.

There are certainly more goners. For instance,

     perl -nE '$c++for/atari/g}{say$c' Configure
     1

AFAIK the last build for Atari was perl 4 patchlevel 19 by Gurusamy
Sarathy. Removing 'atarist ' from Configure would save just 8 bytes, so
that could remain in Configure as a historical reference. And,

     perl -nE '$c++for/atari/g}{say$c' `grep -ril atarist .`
     8
     perl -nE '$c++for/atari/g}{say$c' `grep -ril atari .`
     18

the latter containing matches for 'catarina' and 'qatari' also.

Grepping for other defunct OSes could reveal slightly higher numbers...
No, I won't file a bug report about perl not building on my MEGA2.

0--gg-

-- 
_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                               /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
---1454121964-725701337-1521054499=:20044--
0
gm
3/14/2018 7:08:18 PM

On 03/13/2018 08:05 PM, Karl Williamson wrote:
> There is some complicated code for Ultrix in locale.c that I've never
> been comfortable with.  Now I find that the last release of this OS
> was in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmari
> checked that)
>
> I added this comment some years ago
>
> /* XXX This is to preserve old behavior for Ultrix
>  * when i==0, but I (khw) don't think that behavior makes much
>  * sense */
>
>
> I'd like to get rid of that, and from having to spend time on
> considering this special case when working with this file.
>
> I'm thinking we don't need to keep up support for this OS any longer.

If the OS is outdated and unsupported, it is possible (dare some might
say, likely) it won't build on new versions of Perl for other reasons. A
different problem, raised previously by Jim, I think, is that we have no
way of verifying it still works - and any outdated OS we also do not
have access to makes it doubly difficult to maintain the code for. If
the code in question is in the way, it's good reason to remove it.

Any objections?
0
xsawyerx
3/20/2018 8:01:26 PM
On Tue, 20 Mar 2018 22:01:26 +0200
Sawyer X <xsawyerx@gmail.com> wrote:

> On 03/13/2018 08:05 PM, Karl Williamson wrote:
> > There is some complicated code for Ultrix in locale.c that I've never
> > been comfortable with.=C2=A0 Now I find that the last release of this OS
> > was in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmari
> > checked that)
> >
> > I added this comment some years ago
> >
> > /* XXX This is to preserve old behavior for Ultrix
> > =C2=A0* when i=3D=3D0, but I (khw) don't think that behavior makes much
> > =C2=A0* sense */
> >
> >
> > I'd like to get rid of that, and from having to spend time on
> > considering this special case when working with this file.
> >
> > I'm thinking we don't need to keep up support for this OS any longer. =
=20
>=20
> If the OS is outdated and unsupported, it is possible (dare some might
> say, likely) it won't build on new versions of Perl for other reasons. A
> different problem, raised previously by Jim, I think, is that we have no
> way of verifying it still works - and any outdated OS we also do not
> have access to makes it doubly difficult to maintain the code for. If
> the code in question is in the way, it's good reason to remove it.
>=20
> Any objections?

None from me. Gofer it!

--=20
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
http://www.shlomifish.org/open-source/projects/fortune-mod/

Some people grow older and wiser. Not I. I grow older and more foolish.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
0
shlomif
3/20/2018 8:14:58 PM
On Tue, Mar 20, 2018 at 10:01:26PM +0200, Sawyer X wrote:
> 
> 
> On 03/13/2018 08:05 PM, Karl Williamson wrote:
> > There is some complicated code for Ultrix in locale.c that I've never
> > been comfortable with.  Now I find that the last release of this OS
> > was in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmari
> > checked that)
> >
> > I added this comment some years ago
> >
> > /* XXX This is to preserve old behavior for Ultrix
> >  * when i==0, but I (khw) don't think that behavior makes much
> >  * sense */
> >
> >
> > I'd like to get rid of that, and from having to spend time on
> > considering this special case when working with this file.
> >
> > I'm thinking we don't need to keep up support for this OS any longer.
> 
> If the OS is outdated and unsupported, it is possible (dare some might
> say, likely) it won't build on new versions of Perl for other reasons. A
> different problem, raised previously by Jim, I think, is that we have no
> way of verifying it still works - and any outdated OS we also do not
> have access to makes it doubly difficult to maintain the code for. If
> the code in question is in the way, it's good reason to remove it.
> 
> Any objections?

My (lovely) Ultrix box died a while ago, so I have nothing left on which
to test this.  In general, I would not advocate removing support for an
OS just because we are unable to test it, but there is a difference if
that means managing complicated code just for that OS.  That seems to be
the case here, so in this case I would also not be against dropping
Ultrix support.

As I recall, Ultrix did not support dynamic loading.  Do will still
support any OS with this limitation, or does dropping Ultrix mean that
we can also drop support for only static builds?  And if so, is that
actually of any value or are we just always following the static build
path in that case?  Perhaps Configure can be simplified?

-- 
Paul Johnson - paul@pjcj.net
http://www.pjcj.net
0
paul
3/28/2018 10:54:06 AM
On 03/28/2018 04:54 AM, Paul Johnson wrote:
> On Tue, Mar 20, 2018 at 10:01:26PM +0200, Sawyer X wrote:
>>
>>
>> On 03/13/2018 08:05 PM, Karl Williamson wrote:
>>> There is some complicated code for Ultrix in locale.c that I've never
>>> been comfortable with.=C2=A0 Now I find that the last release of this=
 OS
>>> was in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmar=
i
>>> checked that)
>>>
>>> I added this comment some years ago
>>>
>>> /* XXX This is to preserve old behavior for Ultrix
>>>  =C2=A0* when i=3D=3D0, but I (khw) don't think that behavior makes m=
uch
>>>  =C2=A0* sense */
>>>
>>>
>>> I'd like to get rid of that, and from having to spend time on
>>> considering this special case when working with this file.
>>>
>>> I'm thinking we don't need to keep up support for this OS any longer.
>>
>> If the OS is outdated and unsupported, it is possible (dare some might
>> say, likely) it won't build on new versions of Perl for other reasons.=
 A
>> different problem, raised previously by Jim, I think, is that we have =
no
>> way of verifying it still works - and any outdated OS we also do not
>> have access to makes it doubly difficult to maintain the code for. If
>> the code in question is in the way, it's good reason to remove it.
>>
>> Any objections?
>=20
> My (lovely) Ultrix box died a while ago, so I have nothing left on whic=
h
> to test this.  In general, I would not advocate removing support for an
> OS just because we are unable to test it, but there is a difference if
> that means managing complicated code just for that OS.  That seems to b=
e
> the case here, so in this case I would also not be against dropping
> Ultrix support.

I can answer just this portion of your email.  Yes, there is complicated=20
code for just Ultrix, that I'm not confident works correctly.
>=20
> As I recall, Ultrix did not support dynamic loading.  Do will still
> support any OS with this limitation, or does dropping Ultrix mean that
> we can also drop support for only static builds?  And if so, is that
> actually of any value or are we just always following the static build
> path in that case?  Perhaps Configure can be simplified?
>=20
0
public
3/28/2018 2:56:46 PM
Reply: