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: Sat, 1 Dec 2018 18:58:08 +0000 Message-ID: <20181201185808.GB29324@ACM> References: <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> <874lbxxhtw.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543690818 14916 195.159.176.226 (1 Dec 2018 19:00:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 19:00:18 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: cpitclaudel@gmail.com, Paul Eggert , emacs-devel@gnu.org, martin rudalics , monnier@IRO.UMontreal.CA, Eli Zaretskii To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 20:00:13 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 1gTAUv-0003j4-3m for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 20:00:13 +0100 Original-Received: from localhost ([::1]:42238 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTAX1-0002Hk-Hg for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 14:02:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTAWv-0002Ga-SP for emacs-devel@gnu.org; Sat, 01 Dec 2018 14:02:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTAWr-0007Od-PA for emacs-devel@gnu.org; Sat, 01 Dec 2018 14:02:17 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:38155 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gTAWr-0007Nc-EA for emacs-devel@gnu.org; Sat, 01 Dec 2018 14:02:13 -0500 Original-Received: (qmail 28198 invoked by uid 3782); 1 Dec 2018 19:02:11 -0000 Original-Received: from acm.muc.de (p2E5D5B13.dip0.t-ipconnect.de [46.93.91.19]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 01 Dec 2018 20:02:08 +0100 Original-Received: (qmail 29788 invoked by uid 1000); 1 Dec 2018 18:58:08 -0000 Content-Disposition: inline In-Reply-To: <874lbxxhtw.fsf@web.de> 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:231571 Archived-At: Hello, Michael. On Sat, Dec 01, 2018 at 18:44:27 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > The reaction to my work on this bug, AFTER spending many many days > > hacking it has been uniformly hostile. Not one reply has said "thanks > > for fixing this bug", or anything like it. I'm trying to think of a > > reply which even acknowledged that a bug, a difficult bug, has been > > fixed. > FWIW I really appreciate your efforts, and I hope the final state will > not be to leave the bug unfixed. Thanks! > But I must also admit that the slowdown is a high price, a price that is > in a similar region of annoyance than the bug itself (depending on > personal preferences). I really wished we could find an acceptable way > to soften the slowdown. Going back to Paul's idea of a "double interpreter", how about the following strategy (I don't know enough about the subject even to know if it's a reasonable idea)? We build "bulky" Emacs using the scratch/accurate-warning-pos definitions of EQ, NILP, etc. We then build "slim" Emacs using the traditional definitions of EQ, NILP, etc., such that functions' addresses are the same in both versions. At runtime, when we want to byte compile, get the operating system to switch the mapping of code virtual addresses to the "bulky" code segment. When this is complete, we switch back again. Or something like that. Is this feasible? > Michael. -- Alan Mackenzie (Nuremberg, Germany).