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: Sun, 25 Nov 2018 21:29:20 +0000 Message-ID: <20181125212920.GK27152@ACM> References: <20181117124534.GA8831@ACM> <83muq7u9rk.fsf@gnu.org> <20181123130904.GA2916@ACM> <20181125193050.GH27152@ACM> <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543181444 19695 195.159.176.226 (25 Nov 2018 21:30:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Nov 2018 21:30:44 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, eliz@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 25 22:30:39 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 1gR1zC-0004x5-0n for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2018 22:30:38 +0100 Original-Received: from localhost ([::1]:33179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR21I-0000qt-B5 for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2018 16:32:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR21C-0000qo-2F for emacs-devel@gnu.org; Sun, 25 Nov 2018 16:32:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gR218-0005Mz-QR for emacs-devel@gnu.org; Sun, 25 Nov 2018 16:32:42 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:14312 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gR218-0005Lg-Gv for emacs-devel@gnu.org; Sun, 25 Nov 2018 16:32:38 -0500 Original-Received: (qmail 4857 invoked by uid 3782); 25 Nov 2018 21:32:36 -0000 Original-Received: from acm.muc.de (p2E5D5C08.dip0.t-ipconnect.de [46.93.92.8]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 25 Nov 2018 22:32:36 +0100 Original-Received: (qmail 26379 invoked by uid 1000); 25 Nov 2018 21:29:20 -0000 Content-Disposition: inline In-Reply-To: <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> 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:231374 Archived-At: Hello, Paul. On Sun, Nov 25, 2018 at 12:12:56 -0800, Paul Eggert wrote: > Alan Mackenzie wrote: > > How do other Lisp compilers work? They must have ways of keeping track > > of line and column numbers. > I'm pretty sure they don't redefine the meaning of 'eq'.... Maybe, maybe not. How do they actually do it? I simply don't know, I thought you might. As I said, when we discussed this bug a few weeks ago, we could only come up with bad ways of dealing with it. The current bad way has the advantage of being practical and implementable. > > The problem is that when compilation is in progress, > > (eq 'foo '#) > > has got to return t. > Why not change the byte-compiler to use 'eq-ignoring-symbol-pos' (or > whatever you want to call it) instead of 'eq'? Because of macros. These macros are typically already compiled. > The byte compiler could do this for every occurrence of 'eq' in every > user macro, .... No it couldn't. In this context, "user macro"s include any helper defuns that they call. They would need to be converted, too. To say nothing of quite a few standard Emacs functions, probably. I've no idea how any of this could be done, but suspect it would be more work than reimplementing the byte compiler from scratch. > .... as well as in its own code. This should let ordinary Lisp code > run at full speed; only compilation would be slowed down. The actual slow down is currently uncertain. On benchmarks, Gemini Lasswell has measured between 1% and (?)30% slowdown. On realistic applications (a make bootstrap and scrolling through xdisp.c) I've seen 7 to 8% slowdown. If you could come up with a solid proposal which would fix the bug without slowing down Emacs at all, we'd all be most appreciative. One of the bad ways of dealing with the bug was not to bother fixing it at all. Given how poor the current method is (under 25% hit rate in a bootstrap), I don't think this is a good idea. -- Alan Mackenzie (Nuremberg, Germany).