From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Sat, 1 Dec 2018 12:50:20 -0500 Message-ID: <7faee658-7ad0-4339-00e3-fef198a84121@gmail.com> 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> <20181201172127.GA29324@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1543686505 15826 195.159.176.226 (1 Dec 2018 17:48:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 17:48:25 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 Cc: michael_heerdegen@web.de, Eli Zaretskii , Paul Eggert , monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Alan Mackenzie , martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 18:48:20 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 1gT9NM-00041W-3f for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 18:48:20 +0100 Original-Received: from localhost ([::1]:42064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT9PS-00050L-Oe for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 12:50:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT9PN-00050A-5k for emacs-devel@gnu.org; Sat, 01 Dec 2018 12:50:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gT9PM-0005OY-CZ for emacs-devel@gnu.org; Sat, 01 Dec 2018 12:50:25 -0500 Original-Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]:33133) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gT9PL-0005NO-6R; Sat, 01 Dec 2018 12:50:23 -0500 Original-Received: by mail-qk1-x72e.google.com with SMTP id o89so5098444qko.0; Sat, 01 Dec 2018 09:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YiYbxXVHGKiGqj6oW/VxyEYzfS4QHKLj2MSwogLl290=; b=CIdBFMzb0YokOiNXQgK2tuzJY/ZI4cHRNJL88MjGdlgvzaR6wt5DUsluuI+yTJb7nR 6zugN928l8djMVYFCMAzZkVIGbvEsxJCVPq8XnR6dS2ppemeAaztbd7QVql25wDKzx4Z J0mYGd+gELGbxpLDWIhRjCWsh8WaOoJL8Mj1OlF2rmYiRBqmCYza13d4QluMgmcwgtCl qtBTj6w06qxHWXejalCuA4KMTv1QUZ939py9jKk2BddiF7HW16ZqhapCyTFwQ6p18FXy JGLzSIek9wQw3JswnB1+gA6e3GsGiYyWWDU+0y7WXoH2bXPpY13Pr+tmH2tj3Nb5hPii Ccvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YiYbxXVHGKiGqj6oW/VxyEYzfS4QHKLj2MSwogLl290=; b=JupWPopiYS0klYJFuVw1/moIQv2VDxSrfLwIUCzNCzJqpZYUBhgdWGGaeovEXA9eH/ MQBXo4XEAd2DDA0JAEKKb7hGfFUrXNggm19v1RphkN0KO0kjBWR0cIwO1275YdcvhdlD jfYSFwGE878ULkiZoJQa6ZYxLz/gPZnr9uSxnBOwWX5V5Z20E3SKwLsRw6DqZ+FQgq27 4KlRGntd9VksgC9kAY5S1XeAD4wROR4scceR1feW1Du+jzC8VO7Hu6sEYVTNzVMcD8Vp siIY0CdAFqgGCL/Vg14jfmIWTmPGmtCztrTknAre6kFnCkpStr6+3RNYMsbxQVs/0foD nRKg== X-Gm-Message-State: AA+aEWYgdkZeu38ad9XRikQDD83brLsiHWl1v/KrjoHh97juV5iZNSff F7R7Hpb5k/0cjigAUs/rH9+TUyZQpbE= X-Google-Smtp-Source: AFSGD/VfP8JngfgYuagyk1VNPqIUlu6ptZxK64x3bXBYPIRcx24s0sZBi9QjJMUEX1M6Ucd44D7H3g== X-Received: by 2002:a37:b581:: with SMTP id e123mr9397974qkf.183.1543686622197; Sat, 01 Dec 2018 09:50:22 -0800 (PST) Original-Received: from ?IPv6:2601:184:4180:66e7:9539:5e83:3c38:a0df? ([2601:184:4180:66e7:9539:5e83:3c38:a0df]) by smtp.googlemail.com with ESMTPSA id p3sm5741221qkp.48.2018.12.01.09.50.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Dec 2018 09:50:21 -0800 (PST) In-Reply-To: <20181201172127.GA29324@ACM> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::72e 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:231569 Archived-At: On 01/12/2018 12.21, Alan Mackenzie wrote: > Not one reply has offered to try to help optimise the new code, rather > than discarding it. Hey Alan, I'm very thankful for your efforts to fix this longstanding bug (incorrectly-located warnings are a continuing source of confusion for me, and positions in backtraces, which I think would be a natural extension of your work, would make a lot of debugging work easier). On the other hand, I understand worries about performance. Besides vim, Emacs is roughly the only full-featured editor that runs on my raspberry pi at a reasonable speed. I'm sure there's no malice in the worries expressed by others on this list; rather, it's easy to worry that somewhat costly changes will accumulate until we get performance as bad as many other more recent IDEs. Here's one technical question about the branch: IIUC, your code's strategy is to attach location info to symbols as they are read; this is a clever trick, because macroexpansion tends to preserve symbols more than it preserves conses (interestingly, Racket macros are given syntax objects that include position information instead of raw SEXPs for precisely this reason). But, again IIUC, attaching position information on symbols means that they cannot be compared using pointer equality anymore, which means that EQ must get slower. I wonder: after byte-compiling and reporting accurately-positioned warnings, couldn't we strip position information from symbols, so that usual Emacs execution isn't affected? The idea would be to start by reading in symbols with position information, preserve this position information throughout byte-compilat ion, and then strip it so that the rest of the code can use raw pointer equality. If that is still too slow, could we have two version of read, one acting just like today and one returning sexps whose symbols contain position information? Then we would change the byte-compiler to use the latter, and use eq-with-position-information instead of eq throughout the file. Wouldn't such a scheme make use of the code you wrote, while restricting the performance impact to the byte-compiler and leaving the rest of Emacs unchanged? Cheers and thanks again for your work, Clément.