From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: pipcet@protonmail.com Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Sat, 03 Aug 2024 07:50:21 +0000 Message-ID: <875xsixcxw.fsf@protonmail.com> References: <86y15lzjg6.fsf@gnu.org> <86ttg9zgpb.fsf@gnu.org> <86h6c8zbh8.fsf@gnu.org> <86ikwly80l.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20911"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 03 11:05:04 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1saAhD-0005J9-S8 for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Aug 2024 11:05:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1saAgX-0008Lm-1U; Sat, 03 Aug 2024 05:04:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sa9X5-000287-GP for emacs-devel@gnu.org; Sat, 03 Aug 2024 03:50:31 -0400 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sa9X3-0007PF-91 for emacs-devel@gnu.org; Sat, 03 Aug 2024 03:50:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1722671426; x=1722930626; bh=aHTmRAMfx5xDYxDmASOcfmpZ+S/ZZXzvsVqonfhUcP4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=McsNr3yEu1rM/VVOe04Qfoyi3eGB0mW9SxnxJzVjWbNUZ47R8ujPYpBDGCJeFeSHt dGmTRcoIrog+m/g/tR7iQPjFMfod24ndMiq4LNSEuwCaf5chAxeEAOnG4+AJbJFMHD WFTpFUE4k+goBBubt98iZLGLPdbLG21fA0BxJt3h22CO9nryT57LsS304GMTtJmrx/ t/njtFBTfRGkMQ8DNtRzt/5jrMwqZ99UJI3c7usiDua4w09OWWU8muzvwetUbKmW+g bEuMOaN4Vf+p0RPkU6hUpv0p+p/mySIOUPFyqjFP6ulc/QdmV+AIKPEU9jOZCMgA9J 2iujQEj8KwuMg== In-Reply-To: <86ikwly80l.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 802b9470b61879a117d6b7d95c30a82a70afac0b Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 03 Aug 2024 05:04:15 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322297 Archived-At: "Eli Zaretskii" writes: >> Date: Wed, 31 Jul 2024 06:18:16 +0000 >> From: Pip Cet >> 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 build= s 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, brie= fly, and it starts up and appears to work. However, I cannot do so on a reg= ular 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 direct= ing 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