Re: bug#54245: 29.0.50; select usage in GNUstep

Re: bug#54245: 29.0.50; select usage in GNUstep

[Robert Pluim]

>>>>> On Sat, 05 Mar 2022 20:00:50 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    Po> That LGTM, but I only tested on GNUstep.  The same code is also used on
    Po> macOS, so there might be some side effects.
    >> 
    >> Iʼm on macOS

    Lars> Thanks; I've pushed Robert's patch to Emacs 29 now, and I'm therefore
    Lars> closing this bug report.

I think this means we can now remove the checking for select in
configure, and the HAVE_SELECT define (I took a look, but then ran
into the w32 and msdos ports, and decided to stop :-) )

Robert
-- 

Re: bug#54245: 29.0.50; select usage in GNUstep

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> I think this means we can now remove the checking for select in
> configure, and the HAVE_SELECT define (I took a look, but then ran
> into the w32 and msdos ports, and decided to stop :-) )

AFAICT the MS-DOS port doesn't have select (unless you build it with X11
support, I think), so the define should stay.

nsterm.m used select regardless of the define anyway.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Mon, 14 Mar 2022 17:30:00 +0800
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> > I think this means we can now remove the checking for select in
> > configure, and the HAVE_SELECT define (I took a look, but then ran
> > into the w32 and msdos ports, and decided to stop :-) )
> 
> AFAICT the MS-DOS port doesn't have select

More accurately: the C library used by the MS-DOS port does have
'select', but it is not "good enough" for Emacs purposes, so we use a
separate Emacs-specific implementation in msdos.c.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I think this means we can now remove the checking for select in
> configure, and the HAVE_SELECT define (I took a look, but then ran
> into the w32 and msdos ports, and decided to stop :-) )

I guess so -- perhaps Paul has some comments; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 14 Mar 2022 10:22:13 +0100
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> 
> >>>>> On Sat, 05 Mar 2022 20:00:50 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:
> 
>     Lars> Robert Pluim <rpluim@gmail.com> writes:
>     Po> That LGTM, but I only tested on GNUstep.  The same code is also used on
>     Po> macOS, so there might be some side effects.
>     >> 
>     >> Iʼm on macOS
> 
>     Lars> Thanks; I've pushed Robert's patch to Emacs 29 now, and I'm therefore
>     Lars> closing this bug report.
> 
> I think this means we can now remove the checking for select in
> configure, and the HAVE_SELECT define (I took a look, but then ran
> into the w32 and msdos ports, and decided to stop :-) )

If that's your problem, you could convert HAVE_SELECT into DOS_NT, I
think.

The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Stefan Monnier]

> The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> in msdos.c?),

OMG!  I remember seeing those HAVE_X_WINDOWS and taking for granted that
they were some weird left over from copy&paste.


        Stefan

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Robert Pluim <rpluim@gmail.com>,  luangruo@yahoo.com,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Mon, 14 Mar 2022 09:20:04 -0400
> 
> > The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> > build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> > in msdos.c?),
> 
> OMG!  I remember seeing those HAVE_X_WINDOWS and taking for granted that
> they were some weird left over from copy&paste.

Not copy/paste at all.  See msdos/sed*x.inp and config.bat, where it
supports the --with-x option.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.

When I had the time a few weeks ago, I looked into resurrecting the X11
build on MS-DOS, but could not find any information about an Xlib
implementation for DJGPP.  So I can't help but wonder exactly what
enviroment that build once ran on.

I'd be indebted to anyone with that information.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Mon, 14 Mar 2022 21:34:02 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
> > build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
> > in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.
> 
> When I had the time a few weeks ago, I looked into resurrecting the X11
> build on MS-DOS, but could not find any information about an Xlib
> implementation for DJGPP.  So I can't help but wonder exactly what
> enviroment that build once ran on.
> 
> I'd be indebted to anyone with that information.

The environment was DesqView/X.  It came with a tailored version of
Xlib and other X libraries/utilities that ran on plain MS-DOS using (I
think) the DesqView's own QEMM DOS extender.  This was before DJGPP
v2.x was developed that uses DPMI to switch the processor into
protected mode and run 32-bit protected-mode code that uses virtual
memory.

That's all I know.  I never myself built such an Emacs, and never used
DesqView/X.  See https://en.wikipedia.org/wiki/DESQview for more.

Note that nowadays you'd need such an Xlib compiled with DJGPP v2.x,
which could run in the DPMI environment, so if DesqView/X is still
available somewhere, you will probably need to use QDPMI on plain
MS-DOS.  And if you run on plain MS-DOS, you'd have gazillion problems
with long file names that clash in the 8+3 namespace, because Emacs
stopped trying to be 8+3 clean long ago.

So resurrecting such a build would be a non-trivial project.

Re: bug#54245: 29.0.50; select usage in GNUstep

[Robert Pluim]

>>>>> On Mon, 14 Mar 2022 15:10:09 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> I think this means we can now remove the checking for select in
    >> configure, and the HAVE_SELECT define (I took a look, but then ran
    >> into the w32 and msdos ports, and decided to stop :-) )

    Eli> If that's your problem, you could convert HAVE_SELECT into DOS_NT, I
    Eli> think.

Itʼs not really a problem, itʼs more "Is the issue serious enough to
potentially break builds for other people that I canʼt easily test"

    Eli> The HAVE_SELECT in msdos.c is for the (old and quite defunct) MSDOS
    Eli> build with Xlib (yes, there was such a beast: see those HAVE_X_WINDOWS
    Eli> in msdos.c?), so IMNSHO we can simply drop HAVE_SELECT in msdos.c.

Although this makes it sound like Iʼm worrying too much about
potential breakage.

Robert
--