Re: MPS: Win64 testers?

[pipcet@protonmail.com]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Wed, 31 Jul 2024 06:18:16 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: emacs-devel@gnu.org, rms@gnu.org
>>
>> > Thanks, but this is just a first small step in the right direction.
>> > We need this verified with Emacs, not a small separate test program,
>> > and we need then some serious testing of whatever solution we decide
>> > to implement.
>>
>> I think the bar is slightly lower than that: the code in Emacs is
>> clearly buggy, because it relies on strange and peculiar
>> implementation details that go far beyond anything guaranteed by the
>> API (and that may break at any point on new systems). Replacing it
>> is necessary.
>
> I disagree.

If you disagree that it relies on details that aren't guaranteed by the
API, can you provide an API reference that backs you up?

>> > All of that requires a volunteer who will take upon
>> > him/herself to implement and test the possible solutions on the actual
>> > platform, and then maintaining that and the rest of UCRT-specific
>> > stuff for some reasonably observable future.
>>
>> This isn't UCRT-specific, and, as far as I'm concerned, "the actual
>> platform" is Wine, not Microsoft Windows. If a UCRT build works on
>> wine, it's quite likely to work on Microsoft Windows machines, too.
>
> Not relevant to the requirement of having a dedicated support person.

We don't need a dedicated UCRT support person to unbreak Emacs on
Wine. That's, again, an opinion.

>> > IOW, this needs a
>> > dedicated support person.
>>
>> That's desirable, yes, but hardly necessary.
>
> I disagree, and that's not for you to decide, with all due respect.

I was trying to express an opinion (that fixing a bug shouldn't have to
wait for a test person we haven't driven away yet), not make a
decision. That part is up to you.

>
>> There's a difference between fixing obvious bugs that will prevent builds from ever working and deciding a platform is "officially" supported.
>
> This bug is far from "obvious", and finding a fix for it that will do
> what the original code does requires non-trivial testing.  Until that
> is done, I don't trust the proposed solution (and it was not a
> complete proposal anyway).

I agree that there is a proposed solution we can use, so far. But, yes,
the bug itself is obvious. Throwing away the return value of _fdopen is
simply not something the API allows you to do.

>> FWIW, I've tested my UCRT build on Microsoft's proprietary Windows, briefly, and it starts up and appears to work. However, I cannot do so on a regular basis.
>
> I know.  Neither can I.  Which is why the basic requirement to have a
> dedicated support person on board still stands.

I think it's the other way around: if we fix what UCRT bugs we can, we
can actually look for testers in earnest. But, again, that's an opinion,
and the decision is yours.

>> > The community of Emacs developers cannot allocate resources that don't
>> > exist. And even when they do exist, the ability of the community to
>> > redirect those resources is limited by the opinions and limitations of
>> > the people whose resources need to be redirected.
>>
>> One thing we can certainly stop doing is to discourage people from
>> even looking at stuff. Closing actual bugs as "wontfix" without a
>> sensible explanation, for example, seems counterproductive to me.
>
> Which bugs where "closed as wontfix without a sensible explanation"?

72335

>> > I'm using MinGW and don't intend to install MinGW64 any time soon.
>>
>> Maybe it's time to make that port unofficial, or at least to stop directing people to it rather than the MinGW64 port.
>
> We have been advertising MinGW64 (with MSVCRT) for a long time, see
> nt/INSTALL.W64.  But since it doesn't support Windows versions older
> than Vista (or maybe even that is not supported anymore), we also
> advertise MinGW, which does.

Indeed, but people look at nt/INSTALL first, usually, and that's about
an entirely different port which hardly anyone considers usable at this
point, as far as I can tell.

Pip