From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Fri, 23 Aug 2024 19:17:15 +0300 Message-ID: <86le0np62c.fsf@gnu.org> References: <87bk1k8mzd.fsf@protonmail.com> <861q2gs8xu.fsf@gnu.org> <877cc88j4p.fsf@protonmail.com> <86seuvre6x.fsf@gnu.org> <8734mv8yb6.fsf@protonmail.com> <8634mvqte0.fsf@gnu.org> <87o75j73ry.fsf@protonmail.com> <86v7zrpawy.fsf@gnu.org> <87ed6f6xvc.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39932"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 23 18:18:16 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 1shWzP-000ABn-DH for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Aug 2024 18:18:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shWyY-00039Y-E3; Fri, 23 Aug 2024 12:17:22 -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 1shWyX-000392-5l for emacs-devel@gnu.org; Fri, 23 Aug 2024 12:17:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1shWyV-0004XC-EE; Fri, 23 Aug 2024 12:17:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=76PnnZtCHEJiFPpNw87hojwlgoCRBQV1g5B4lJywnRQ=; b=jIVkMQ7Lvd/X Fguz4yOU4bRfwDR+wi6BXT7Ypsw3QK5gSe2N2PO15VBI2ib1i6moPfaVPiZo4fXEjxtvLclR0pc3q BU/mrZGG0dzlDD/soVOg4bX2M2/9E0NULn2fDOgOG5qm/6fBX/v5jRqQ1/C+Tgu58nCSpHBnpDLQY kZ8sx275/CBRvw5IxUIavtACvWViJZXrSyhb77Y7rk+RS1xrRTYxVymDKICgRR7PUf77EzasDvb4n xH3RgbCBVR3xzDFrpMFh8GPtmldtgI4KvuJwaSdxV+3QTZCDcKhPKYRO5VKjlaAFVe2pVRk/wS2fS zNVcWYpx+ThkCuhV4gdYqw==; In-Reply-To: <87ed6f6xvc.fsf@protonmail.com> (message from Pip Cet on Fri, 23 Aug 2024 15:51:41 +0000) 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:323094 Archived-At: > Date: Fri, 23 Aug 2024 15:51:41 +0000 > From: Pip Cet > Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net > > "Eli Zaretskii" writes: > > >> So I think this could improve Emacs in general, even for people who will > >> never use MPS. > > > > We are not coding Emacs from scratch. Emacs is already a very large > > body of code, most of it tested by time and gobs of users and use > > patterns. To start rewriting too much of that means we are losing all > > that hard-earned stability, because many corners in Emacs code are not > > well known to those who are currently active in development and > > maintenance. > > > > So from where I stand, it is definitely a significant problem to make > > such vast changes, and the fact that it will help us eventually > > doesn't help. Because if we destabilize Emacs enough, we will lose > > our users, which are the only reason Emacs is still alive and kicking. > > I don't see how we'd destabilize the existing Emacs code by making such > changes; any unconverted code would continue working as it did before > without MPS, and continue not working with MPS. I'm talking about the code changes, not about what stays unchanged. And if you don't understand how adding a lot of changes of this particular kind can destabilize Emacs, then I guess we have very different perspectives on stability, and this line of discussion between us is not useful. > If your point is that it might be a long time until MPS is stable enough > for very unusual configurations, that is certainly true, and affects > when it's a good idea to enable it for general use. Not "for very unusual configurations", for all configurations, including the most popular ones. We are touching the most delicate parts of Emacs, and will probably touch a lot of them (unless we find some simpler, more reliable way of preventing these problems). > >> This particular call is safe. 'match_data' lives on the stack, MPS > >> treats the stack conservatively as pinning every object to which it > >> might possibly refer, thus 'match_data->pattern' cannot be moved. > > > > IOW, we are lucky. Because match_data could well be a global variable > > allocated off the heap, or something else. > > Which would be a bug both with and without MPS, as nothing protects > match_data.list from GC if it doesn't live on the stack. ??? We have gobs of those, and know how to protect them. The easiest way is staticpro, and there are others. > >> The change I proposed is redundant: it tells MPS not to move the > >> pointer, and it uses a pointer-to-a-pointer to catch potential moves. > >> Only one part of that is needed, but in both cases, we need to remember > >> to un-pin/free something. > > > > If the change is redundant, why did you propose it? > > Better to solve a problem twice than not to solve it at all? Not in my book, no. Since Emacs is stable, we should not add any code that is not strictly necessary, otherwise we risk unnecessary problems. > I don't see a problem there, to be honest. > > (It's morally equivalent to writing > > if (p) > xfree (p); > > even though that's redundant as well.) It's nowhere morally equivalent to the above, because it is much harder to understand what goes on with MPS than to figure out that xfree tests NULL internally.