From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Sat, 1 Dec 2018 17:21:27 +0000 Message-ID: <20181201172127.GA29324@ACM> References: <20181129220552.GI12576@ACM> <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu> <20181130185503.GA16256@ACM> <20181130220218.GB16256@ACM> <138d56b7-53df-1ea5-377c-8502245f1b6b@cs.ucla.edu> <5C0239DA.4030907@gmx.at> <20181201124727.GC5102@ACM> <5C02962C.5040505@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543685021 24166 195.159.176.226 (1 Dec 2018 17:23:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 17:23:41 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: cpitclaudel@gmail.com, Paul Eggert , michael_heerdegen@web.de, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 18:23:36 2018 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 1gT8zP-00067a-78 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 18:23:35 +0100 Original-Received: from localhost ([::1]:42013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT91V-0001c6-I7 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 12:25:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT91M-0001au-0n for emacs-devel@gnu.org; Sat, 01 Dec 2018 12:25:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gT91H-0002QF-6I for emacs-devel@gnu.org; Sat, 01 Dec 2018 12:25:36 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:39963 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gT91G-0002Pl-RR for emacs-devel@gnu.org; Sat, 01 Dec 2018 12:25:31 -0500 Original-Received: (qmail 99114 invoked by uid 3782); 1 Dec 2018 17:25:29 -0000 Original-Received: from acm.muc.de (p2E5D5B13.dip0.t-ipconnect.de [46.93.91.19]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 01 Dec 2018 18:25:27 +0100 Original-Received: (qmail 29474 invoked by uid 1000); 1 Dec 2018 17:21:27 -0000 Content-Disposition: inline In-Reply-To: <5C02962C.5040505@gmx.at> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:231565 Archived-At: Hello, Martin. On Sat, Dec 01, 2018 at 15:09:48 +0100, martin rudalics wrote: > Hello, Alan > >> There are around 50 issues in current Emacs that annoy me at least as > >> much as wrong positions reported by the byte compiler. > > Likely, none of them are as difficult to address as the byte compiler > > bug. > Running an incremental copying collector in a separate thread is, for > example. Possibly. Has anybody raised a bug report concerning (the lack of) an i.c.c.? > > But who's going to address them, if they can expect the reaction > > I'm getting at the moment? > I've been following this thread since its beginning and I've not seen > an unjustified reaction so far, including mine. The reaction to my work on this bug, AFTER spending many many days hacking it has been uniformly hostile. Not one reply has said "thanks for fixing this bug", or anything like it. I'm trying to think of a reply which even acknowledged that a bug, a difficult bug, has been fixed. Not one reply has offered to try to help optimise the new code, rather than discarding it. I'm not entirely sure either that those criticizing entirely understand what has been fixed. Paul E. admitted as much in his latest post. > I've kept quiet when the 'open-paren-in-column-0-is-defun-start' > convention was abolished recently. And I would have kept quiet in the > case at hand as well. But Eli once said that people should complain > _before_ a change is made and so I did. Nobody complained before I put in 50 - 100 hours of work fixing the bug. Or if they did, I wasn't listening. Perhaps if they had, I might have not bothered fixing it, given that people don't really seem to want it fixed anyway. > >> If, on the average, solving any such issue took away just 2% of the > >> performance of my Emacs, I'd experience an overall slowdown of 100% > >> when solving all of them. So please note that Paul is not alone with > >> his concerns. > > On average, solving these other bugs will cost 0% in performance. > > You're positing a completely unrealistic scenario. > Right. But mainly so because many of these 50 problems should have a > solution in the opposite direction. They aim at improving performance > rather than degrading it. For example, I spent quite some time on > reducing the overhead associated with creating Emacs tooltip frames - > largely unnoticed, but it saves me an entire GC cycle for every > tooltip displayed here. Why should I spend my time on such things if > any gains are annihilated by solutions like yours. The solution to this bug would be the same regardless of who implemented it. The improvement in performance from your changes will be the same regardless of whether my bug fix is merged in or not. > > Have you even tried scratch/accurate-warning-pos? You've said in the > > past that you have a slow machine, so if that's still true, you would > > probably be the person to notice perceptible slowdown, should there be > > any. Do you notice any slowdown with it? > I haven't tried it. As a rule, I bootstrap each of my Emacs instances > once a year, after Glenn changed the file headers. Here a bootstrap > means that I can't use my machine for more than an hour. And after my bug fix a bootstrap would still take "more than an hour". You'd scarcely notice the difference. > And that I have to either make a separate copy of my Emacs tree or do > another bootstrap to return to the previous version. This year I > already made one extra bootstrap for the portable dumper and that > consumed enough of my remaining energy for such endeavours. You have > to live with the fact that people like me live in a different world. Yes. I haven't forgotten doing overnight builds on Emacs myself. But you also have to live with acknowledging most people's typical setup, as I'm sure you do. > > The byte compiler bug is extremely unusual, possibly unique, in its > > resistance to being resolved. Just about every possible approach has > > been tried (along with several which are not possible), and only one > > approach, the one in scratch/accurate-warning-pos, has got anywhere at > > all. > > If you still object to this fix, even after trying it, what you are > > saying is that you prefer fast buggy software over slightly slower > > functional software. > I don't say that. You are saying that. You're saying that the 7% - 8% or whatever slowdown is more important to you than a bug free byte compiler. > IMO the "byte compiler bug" has a simple fix which, however, nobody but > me would accept: When there is the slightest doubt do not print > position indications. This would mean printing no positions at all. In a bootstrap (which I've done rather a lot of, recently) only 25% of the positions output are correct. The other three quarters are junk. Likely the pattern is repeated in compilations of users' programs. Apparently, nobody but me thinks this is a Bad Thing. > Also I don't understand why it should be the byte compiler's task to > check the syntax of expressions for correctness. If the byte compiler > raises an error or new Lisp code should be compiled, run a separate > syntax checker that gets as close as possible to the source of any > error in the code. That wouldn't help. The difficulty is associating a source code position with the (read) code, which is being steadily transformed. This would be the same regardless of whether the byte compiler itself or some separate bit of code does the checking. > And it can spend as much time on that as it needs. But enough heresy > here. What takes the extra time is that EQ, NILP, SYMBOLP, and XSYMBOL have been amended to recognize, when a flag is set, that # is the same as foo. It is the testing of that flag which takes the time, even when it is not set. > martin -- Alan Mackenzie (Nuremberg, Germany).