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 20:26:16 +0000 Message-ID: <20181201202616.GC29324@ACM> References: <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> <20181201185808.GB29324@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543696136 28081 195.159.176.226 (1 Dec 2018 20:28:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 20:28:56 +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 21:28:51 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 1gTBsh-000793-79 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 21:28:51 +0100 Original-Received: from localhost ([::1]:42463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTBun-0001xC-M0 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 15:31:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTBuC-0001ws-2h for emacs-devel@gnu.org; Sat, 01 Dec 2018 15:30:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTBu8-0007Ew-U3 for emacs-devel@gnu.org; Sat, 01 Dec 2018 15:30:24 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:51707 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gTBu8-0007EQ-IS for emacs-devel@gnu.org; Sat, 01 Dec 2018 15:30:20 -0500 Original-Received: (qmail 51740 invoked by uid 3782); 1 Dec 2018 20:30:19 -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 21:30:16 +0100 Original-Received: (qmail 31831 invoked by uid 1000); 1 Dec 2018 20:26:16 -0000 Content-Disposition: inline In-Reply-To: <20181201185808.GB29324@ACM> 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:231578 Archived-At: Hello again, Michael. On Sat, Dec 01, 2018 at 18:58:08 +0000, Alan Mackenzie wrote: > 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)? [ .... ] No, I don't think that idea (snipped) was at all good. If it could work, it would be a security nightmare. Instead, how about this: We build (part of) Emacs using the scratch/accurate-warning-pos versions of EQ, NILP, .... Using some object code utility, we systematically change the names of variables, constants, ...... We note the addresses of the subrs (of which there are a mere 1450). Call this the "bulky" version. We build the "slim" Emacs, then link them together into temacs. At run time, when we do byte compilation, we first set the function addresses of (most of?) the subrs to the "bulky" subrs, perform the compilation, then restore them again. The main disadvantage would be the increased size of temacs, approximately doubled. The advantage would be that "normal" Emacs would run at "full speed". > > Michael. -- Alan Mackenzie (Nuremberg, Germany).