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: Thu, 29 Nov 2018 22:05:52 +0000 Message-ID: <20181129220552.GI12576@ACM> References: <20181126184359.GG4030@ACM> <55044caa-18fb-9e9a-81b4-3912f64d0aa4@cs.ucla.edu> <20181127074336.GA4705@ACM> <0ec5806a-0cc6-8b9f-6bc2-97875e36a511@cs.ucla.edu> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543529380 28870 195.159.176.226 (29 Nov 2018 22:09:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2018 22:09:40 +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 Thu Nov 29 23:09:35 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 1gSUV4-0007Qd-8o for ged-emacs-devel@m.gmane.org; Thu, 29 Nov 2018 23:09:34 +0100 Original-Received: from localhost ([::1]:56790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSUXA-0007kC-Qp for ged-emacs-devel@m.gmane.org; Thu, 29 Nov 2018 17:11:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSUVB-0006Sk-O8 for emacs-devel@gnu.org; Thu, 29 Nov 2018 17:09:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSUV8-000610-0R for emacs-devel@gnu.org; Thu, 29 Nov 2018 17:09:41 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:23331 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gSUV7-00060X-MI for emacs-devel@gnu.org; Thu, 29 Nov 2018 17:09:37 -0500 Original-Received: (qmail 93498 invoked by uid 3782); 29 Nov 2018 22:09:37 -0000 Original-Received: from acm.muc.de (p2E5D5BA2.dip0.t-ipconnect.de [46.93.91.162]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 29 Nov 2018 23:09:34 +0100 Original-Received: (qmail 11133 invoked by uid 1000); 29 Nov 2018 22:05:52 -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:231524 Archived-At: Hello, Paul. On Thu, Nov 29, 2018 at 13:28:06 -0800, Paul Eggert wrote: > On 11/28/18 4:04 AM, Alan Mackenzie wrote: > > Assuming the macro is compiled, just where are these cons positions > > going to be stored? > The same place we store the rest of compiled output. That is, when we > byte-compile macros, we store the uncompiled macros (with source-pos > info) into the .elc file. Then, any code that wants accurate line number > or similar debugging information for the macro can use the uncompiled > version. It's pretty common to bloat object files to support debugging > in this way. > This approach wouldn't work for .elc files generated by older versions > of Emacs, but that's OK; the old macros should still work, it's just > that the byte-compiler's diagnostics will be just as bad as before. The above is completely irrelevant to the question at hand. We're not talking about macros generating messages for invalid input. we're talking about generating message positions for the source being compiled. [ .... ] > > You're wrong, here. Symbols-with-pos works on the output from macros. > > Conses-with-pos will only do so for some "nice" macros, ones which > > preserve their input conses. > I'm afraid we'll have to disagree here, as I can see examples where > symbols-with-pos fails .... I can't. Please give an example, so I can see what you're talking about. > .... and conses-with-pos works (as well as vice versa). The only good > way I see to resolve the disagreement would be to build it both ways > and see which typically works better in the real world. A daunting > prospect, admittedly. Symbols-with-pos exists, works, and works well. Conses-with-pos doesn't exist, hence doesn't work. I doubt it can work. Can you create it? To create scratch/accurate-warning-pos took a fair amount of work, but not that much. You can work much faster than I can, so why don't you hack up a version of the byte-compiler which uses positions of conses to track source positions? Bring it to the point where it can successfully bootstrap Emacs. Then we can compare the two approaches. -- Alan Mackenzie (Nuremberg, Germany).