From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Fri, 30 Nov 2018 15:46:23 -0800 Organization: UCLA Computer Science Department Message-ID: <138d56b7-53df-1ea5-377c-8502245f1b6b@cs.ucla.edu> 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> <20181130220218.GB16256@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1543621509 28434 195.159.176.226 (30 Nov 2018 23:45:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 23:45:09 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 00:45:05 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 1gSsT2-0007G5-Ej for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 00:45:04 +0100 Original-Received: from localhost ([::1]:35162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSsV8-0007XL-Ry for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2018 18:47:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSsUR-0007XG-NV for emacs-devel@gnu.org; Fri, 30 Nov 2018 18:46:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSsUQ-0001MF-OD for emacs-devel@gnu.org; Fri, 30 Nov 2018 18:46:31 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42334) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gSsUM-0001LI-SX; Fri, 30 Nov 2018 18:46:27 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 747B7160524; Fri, 30 Nov 2018 15:46:25 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pTe7pp8yIF-f; Fri, 30 Nov 2018 15:46:24 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8D182160527; Fri, 30 Nov 2018 15:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W4bPS3R3-OHM; Fri, 30 Nov 2018 15:46:24 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6F83716005B; Fri, 30 Nov 2018 15:46:24 -0800 (PST) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <20181130220218.GB16256@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:231545 Archived-At: On 11/30/18 2:02 PM, Alan Mackenzie wrote: >> 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. I value performance and the error message location issues don't bother me much in practice, perhaps partly because I tend to break Lisp code into smaller pieces so the exact location of the error doesn't matter that much. Evidently your preferences differ: the location issues bother you, and your machine is faster and/or you don't mind the performance hit. That doesn't make you right and me wrong, or vice versa. It's a matter of balancing priorities. > Remember, in a bootstrap, only 25% of > these locations are correct. People notice, and it makes us maintainers > look incompetent and stupid. My impression is more that it's the presence of the diagnostics, not the line numbers in the diagnostics, that are makes us developers look "incompetent and stupid" (I would say "spread too thin" but maybe that's just me :-). And even if this were a public-relations issue that could be fixed by proper line numbers (an assertion I'm skeptical of), I proposed a solution that will work for this particular issue and won't involve slowing down Emacs significantly in ordinary use, namely, use a separate Emacs binary for batch byte compiling when bootstrapping. >> 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. Sure, and my alternative then was to live with Emacs as it is. That's preferable to making Emacs significantly slower for a relatively minor benefit. > >> 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. It would work for the test case in Bug#9101. It no doubt would not work for some other examples. The point is that it's not clear (to me, at least) what the scope of the problem is, and we don't seem to be making progress on delineating the scope, and without knowing the scope it's hard to suggest or evaluate alternative solutions. > 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. > All in all the status quo is preferable to scratch/accurate-warning-pos. Although I don't expect you to agree with me on this, I don't think I'm alone in having concerns about the significant performance issues here.