From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Sat, 03 Dec 2016 01:34:42 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> <83bmwuogfb.fsf@gnu.org> <878trydrbo.fsf@red-bean.com> <83a8cem1eq.fsf@gnu.org> <83zikdl7oo.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480757714 7983 195.159.176.226 (3 Dec 2016 09:35:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2016 09:35:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: kfogel@red-bean.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 10:35:06 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cD6in-0000nc-TB for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 10:35:06 +0100 Original-Received: from localhost ([::1]:42018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cD6ir-0005I3-Re for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 04:35:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cD6if-0005GA-TJ for emacs-devel@gnu.org; Sat, 03 Dec 2016 04:34:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cD6ie-000785-HQ for emacs-devel@gnu.org; Sat, 03 Dec 2016 04:34:57 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:34174) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cD6ie-000774-51; Sat, 03 Dec 2016 04:34:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=gX8lqtfbrGnJzavBPodYES2PE2e31ol2yo4+CYfw5rc=; b=aBRk+ltjfNQBAZDO0j8EAuhuODeCR2i2UrQANCDI4X6btZAe7LSuOvK1+xzVi5+K1ogcZWFDtNYkMoJtc8FEwt0DKdylN5BoCPT+rWpPK1hxzKFCnd7SKNyNosCb7QP6ocd+apJ8bKricTSgUwcuZy33slWAXYSQuFfwy88ug97PXrZ0CBmnqCeFDtdSxQX2sfjb2HBJAQGgwHwOlPG8l15msvvJjZ4aaM8eyosYMDBXEIc679GRaxuDdsMLRFWYtop0+SlITVbq2mOc3NIoVwsfufKbrP3uJhvRHDQ0L1KjcjLsJ/bRYKF2vLful32Y1x49ixjj859fPC44zg+P9Q==; Original-Received: from [2601:602:9802:d9d1:8899:d2fd:9631:748c] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cD6iW-0001Fj-N9; Sat, 03 Dec 2016 01:34:48 -0800 In-Reply-To: <83zikdl7oo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Dec 2016 10:48:23 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209976 Archived-At: On Sat, Dec 03 2016, Eli Zaretskii wrote: >> From: Daniel Colascione >> Cc: Karl Fogel , emacs-devel@gnu.org >> Date: Fri, 02 Dec 2016 14:28:25 -0800 >> >> We've all been contributing to Emacs for many years. I think we have a >> pretty good grasp of the issues and potential problems. I understand >> that you think there's an existential risk that goes into this change, >> but I think you're mistaken, and a lot of other people agree. We all >> have access to the same information; it's unlikely (but not impossible) >> that you're the only one who can see certain potential problems. > > Assessment of trends and their impact on the future, with all the > uncertainties involved, requires more than just processing the > immediately available information. What information then? We are both rational creatures. If we disagree, it's either because one of us made a leap of logic that other has not or because we're starting with different postulates. Can we please get at the root of our disagreement? What evidence would convince you that you were incorrect? On my part, I might be swayed by examples of other free software projects that have failed due to the inclusion of C code. I cannot think of any. It is very frustrating to be asked to believe radical assertions made without any evidence; that's what happened on the thread-safe malloc thread, and it was very unproductive. >> Please give this change the benefit of the doubt. > > I thought I was already doing that. Isn't that why the code will be > on a branch soon? The branch will be short-lived. I will want to merge this code soon. It's at that time that I will most appreciate being given the benefit of the doubt. >> Even if your worst-case scenario comes to pass, the worst outcome >> outcome will just be more fiddly maintenance. > > We already have such "fiddly maintenance" situation in several areas. > Font selection, font back-ends, character composition, complex script > shaping, and (to some extent) the interaction with X and its window > managers -- all of these are areas where bugs are left for months and > years without being fixed, and no progress is made to adapt Emacs to > the new technologies out there. The reason that these bugs aren't getting fixed is that they're not bothering people enough to provoke fixes. I know that I'm much more inclined to fix bugs when they bother me personally. It's misleading to cite unfixed minor bugs as evidence that nobody knows how to fix the bugs. Placing restrictions on the people who do know how to fix these bugs is a good way to ensure that we'll either leave them unfixed (thinking it not worth the trouble to justify the addition of C code) or just keep the fixes local (which I confess to doing, for this reason). You know why I haven't worked on the GTK+-only backend I proposed? I don't *need* to yet. The X11 one works fine, with fixes here and there. One day, it won't work fine anymore, and either I or someone else will make it work fine. This situation is not evidence that we're forgetting how to program GUIs. It means that we did an adequate job. As for "adapting Emacs to the new technologies out there": that is precisely what the portable dumper does! I sent a patch that adapts Emacs to modern technologies and you're complaining that nobody is doing that. What do you expect me to think? > IOW, "the worst outcome" is already here. I'm desperately trying not > to make it worse. Emacs runs fine and has many users. It's influential in the community. I have no idea how many users we have, but I find Emacs users in every group of developers I visit. emacs-devel is a high traffic mailing list. We make the news on every major release. If this situation is "the worst outcome", the worst outcome is pretty comfortable. Bugs in the sections of code you mention get fixed when you allow them to get fixed --- Stefan had to try very hard recently to get the before-change-functions bug fixed, and that was a simple fix for an egregious problem. >> I think the pdumper code is pretty clean; I'm open to suggestions >> for making it moreso. > > I will definitely try to keep this in mind when reviewing the code. > However, code cleanness is not the main problem, based on the above > examples. There's nothing unclean in the code in any of the areas I > mentioned. The problems are elsewhere. Yes. I don't think anyone is concerned about code quality. There is literally nothing I know how to do to this code to make you feel better about merging it. I feel like the code's very existence is what bothers you, and I can do nothing about that except give up, which I won't do. If my assessment is incorrect, and there is something I can do to the code to make you feel better about it, please let me know. >> If there's no one left who can understand pdumper, there's no one >> left who can understand the GC either. > > GC is stable for many years, and "just works". Bugs only happen there > when people make changes in GC code, for benefits that are not > essential. If there's no one on board who understands GC, we can > simply disallow any changes in that area. The surest way to ensure that nobody understands a piece of code in a free software project is to put up a big sign that says "OFF LIMITS! DO NOT TOUCH!". People learn by doing. You need to let people experiment. Moving fast (and breaking things occasionally) beats OWNERS. Emacs is not pacemaker firmware. It's not flying an airplane. A bug introduced is not the end of the world. We can bisect. You can't simultaneously lament that the flow of new core developers is a trickle and keep the spigot turned off. Your position on this matter has never made any sense to me. > By contrast, the portable dumper is new code. No matter how simple > and clean, it will take some time until it becomes mature enough to > raise to the current status of GC. Until that happens, we cannot > afford being in the same situation as with GC. Half the people on emacs-devel understand the GC. The other half could understand it with a few days of study. The last time we had a major GC bug (the purespace symbol reference thing), we quickly had two independent patches for fixing it. (Mine lost, but that's history.) Both of those path authors are on this thread. This outcome doesn't suggest that GC is in danger of becoming abandonware. If pdumper ends up in the same position GC is in today, that's fine. Speaking of future-proofing Emacs: I'd appreciate fixing the conservative GC problem I highlighted a few days ago before it becomes a real bug. Maybe I misread the messages, but my sense was that you were firmly against that change as well, and I never figured out why. >> You won't have to touch this code. > > I most probably will, and I have no reason to be afraid of that. But > this isn't about me. You are the only one objecting. Perhaps, generally speaking, your opinion carries greater weight, but it should not carry infinite weight. Please defer to the judgment of the rest of the community. This change is not an existential threat. We are not the enemy.