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 19:30:50 +0000 Message-ID: <20181125193050.GH27152@ACM> References: <20181117124534.GA8831@ACM> <83muq7u9rk.fsf@gnu.org> <20181123130904.GA2916@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543174378 7030 195.159.176.226 (25 Nov 2018 19:32:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Nov 2018 19:32:58 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, eliz@gnu.org, 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 Sun Nov 25 20:32:54 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 1gR09F-0001iP-CW for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2018 20:32:53 +0100 Original-Received: from localhost ([::1]:60998 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR0BL-0006K1-Uf for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2018 14:35:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR0Ae-0006IS-Vu for emacs-devel@gnu.org; Sun, 25 Nov 2018 14:34:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gR0AZ-0000Ec-Tn for emacs-devel@gnu.org; Sun, 25 Nov 2018 14:34:20 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10633 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gR0AW-0000Br-Dh for emacs-devel@gnu.org; Sun, 25 Nov 2018 14:34:14 -0500 Original-Received: (qmail 63459 invoked by uid 3782); 25 Nov 2018 19:34:08 -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 20:34:05 +0100 Original-Received: (qmail 20844 invoked by uid 1000); 25 Nov 2018 19:30:50 -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:231364 Archived-At: Hello, Paul. On Sun, Nov 25, 2018 at 10:45:09 -0800, Paul Eggert wrote: > I didn't realize until now that this branch makes EQ slower for everybody, .... Yes. That is why I have been so concerned about the speed, right from the beginning. > .... for what seems to be a relatively minor issue (i.e., more accurate > diagnostics). .... Well in the branch I'm working on, there are 335 warnings with a position, and the old way of doing things gave the correct position in only 81 of these, being wrong in the other 254. There have been quite a lot of bug reports about wrong warning positions. > Surely there is a better way. Stefan, Eli, and I had quite an extensive discussion about possible approaches two or three or four weeks ago. Our conclusion (formulated by me) was that there was no good way of resolving the bug, only varying degrees of bad ways. How do other Lisp compilers work? They must have ways of keeping track of line and column numbers. > Why not add an option to 'read' so that its returned value contains > symbol-with-pos objects instead of symbol objects? That's more or less what's been done, except that there's a second function called read-positioning-symbols alongside read. > That way, programs like the Elisp compiler that read objects can > generate more accurate diagnostics without having to slow down EQ for > everybody. The problem is that when compilation is in progress, (eq 'foo '#) has got to return t. I can't see a better way of doing this than testing the variable symbols-with-position-enabled at each failing == operation. If you have any better suggestions, I'd love to hear of them. -- Alan Mackenzie (Nuremberg, Germany).