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: Fri, 30 Nov 2018 22:02:18 +0000 Message-ID: <20181130220218.GB16256@ACM> References: <20181127211539.GB4705@ACM> <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> <20181127215347.GC4705@ACM> <23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu> <20181128120443.GA4036@ACM> <20181129220552.GI12576@ACM> <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu> <20181130185503.GA16256@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543616062 12917 195.159.176.226 (30 Nov 2018 22:14:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 22:14:22 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 30 23:14:17 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 1gSr39-0003AE-6Z for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2018 23:14:15 +0100 Original-Received: from localhost ([::1]:34890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSr5F-0008Ur-GO for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2018 17:16:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSqvR-0006A3-Qh for emacs-devel@gnu.org; Fri, 30 Nov 2018 17:06:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSqvM-0008MU-Kc for emacs-devel@gnu.org; Fri, 30 Nov 2018 17:06:17 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:62034 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gSqvM-0008Bg-6C for emacs-devel@gnu.org; Fri, 30 Nov 2018 17:06:12 -0500 Original-Received: (qmail 10200 invoked by uid 3782); 30 Nov 2018 22:06:10 -0000 Original-Received: from acm.muc.de (p2E5D5BA4.dip0.t-ipconnect.de [46.93.91.164]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 30 Nov 2018 23:06:08 +0100 Original-Received: (qmail 18667 invoked by uid 1000); 30 Nov 2018 22:02:18 -0000 Content-Disposition: inline In-Reply-To: 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:231543 Archived-At: Hello, Paul. On Fri, Nov 30, 2018 at 12:14:59 -0800, Paul Eggert wrote: > On 11/30/18 10:55 AM, Alan Mackenzie wrote: > > There are no performance "issues". Emacs with this bug fix is minutely > > slower than without it, not enough to matter. > I'm afraid we'll have to disagree about that. It's not worth slowing all > Emacs computations by 3.5% - 10% or whatever, merely to get > more-accurate locations in byte-compiler diagnostics. Please stop being so disparaging. There's nothing "mere" about accurate compiler messages, and the current bug fix delivers CORRECT locations, not "more-accurate" ones. > That is a significant slowdown, .... No it isn't. We could sit you down in front of each version of Emacs, get you to play with them, and you would be unable to distinguish them without using a machine to do timings. > .... and it's too much of a price to pay for such a small benefit. You think having compiler messages whose locations simulate a random number generator is acceptable? Remember, in a bootstrap, only 25% of these locations are correct. People notice, and it makes us maintainers look incompetent and stupid. > I too have played with the idea to redefine eq, for a different purpose > (so that bignums behave more like fixnums), and I gave it up because of > similar slowdowns. It wasn't worth the cost there either. No doubt, you found some alternative. What you're saying is that being fast is more important than working properly. Taking that attitude to extremes, Emacs could be considerably speeded up by removing some safety and sanity checks. > Sometimes ideas just don't work out. You're not willing to work on an alternative, though. You weren't even in on the conversation when we were discussing alternatives (or, more precisely, the lack of alternatives). > > The point of the exercise is specific, not vague as you have > > misformulated it. It is to print the correct source locations in > > compiler warnings which are currently being output as wrong locations. > > For example, read bug #9109. > Bug #9109 could be fixed by a read variant that returns > symbols-with-positions, by changing the byte-compiler to understand > the output of this read variant, and by having the byte compiler > remove position information before passing a subexpression to a macro. That wouldn't work. Macro expansion is done at an early stage of compilation. You can't remove arbitrary position information and still expect to get accurate (or indeed any) positions in compiler messages. > It could also be fixed by a read variant that returns > conses-with-positions. Only by rewriting the compiler such that that information is somehow preserved as compilation progresses. As long as you don't have any macros which massage the code, that is. > Neither fix would slow down ordinary code. These were all considered earlier on, and dismissed as impractical or non-working. > However, as I understand it, we don't want either fix because these > fixes would still generate subpar locations in diagnostics when > byte-compiling other code that calls macros. If by "subpar" you mean no location at all (beyond, perhaps, the name of the top-level function), then subpar describes it well. And you're talking about most code, typical code, here. What proportion of defuns doesn't contain a `when'? Even `defun' itself is a macro. ;-( > This is why I have been thinking about other code errors that involve > macros, errors that you say are out of scope. They are out of scope, yes. Expanding the scope into vague abstract territory is an excellent way of postponing a solution for ever. > When trying to consider alternatives to scratch/accurate-warning-pos, I > was trying to get an understanding of problem scope that is independent > of the proposed solution. Unfortunately I failed to do that, and this > makes it difficult to consider alternatives. Eli, Stefan and I had a wide ranging discussion about the possibilities. If there had been alternatives, likely we would have stumbled across them. Maybe we missed something. Feel free to take up that other thread again if you've got anything to add. But at the moment, scratch/accurate-warning-pos is looking like the only pracaticable solution to these many bugs. It is a bad solution, yes, but there are no good ones, and it is the least bad from what's available. -- Alan Mackenzie (Nuremberg, Germany).