From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs-devel Digest, Vol 166, Issue 137 Date: Fri, 22 Dec 2017 22:06:36 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1513998298 16699 195.159.176.226 (23 Dec 2017 03:04:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 03:04:58 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 23 04:04:54 2017 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 1eSa7H-0003rN-NI for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 04:04:51 +0100 Original-Received: from localhost ([::1]:39833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSa9F-0000LR-Vj for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 22:06:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSa97-0000Kl-BJ for emacs-devel@gnu.org; Fri, 22 Dec 2017 22:06:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSa96-0001Qc-C1 for emacs-devel@gnu.org; Fri, 22 Dec 2017 22:06:45 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:42439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSa92-0001Kp-IV; Fri, 22 Dec 2017 22:06:40 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id vBN36aZ9026736; Fri, 22 Dec 2017 22:06:37 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 7869A662D4; Fri, 22 Dec 2017 22:06:36 -0500 (EST) In-Reply-To: (Rocky Bernstein's message of "Fri, 22 Dec 2017 21:42:48 -0500") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6186=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6186> : inlines <6281> : streams <1773903> : uri <2555828> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:221364 Archived-At: >> No, I'm thinking rather of not keeping the bytecode file around at all, >> or to store it in an "internal cache" (which could be kept in the >> file-system but could be erased at any point and without any command to >> "load a bytecode file"). > Sounds like a JIT. Yes and no. JIT usually applies to the case of generating machine code, whereas the above scheme doesn't necessarily imply anything else than the current scheme of compiling to a .elc file. > Is there *any* testing done running emacs code on older bytecode, either in > the normal course of testing or before a release? Testing, as in a test-suite? No. Only testing in the form of people out there trying out Emacs from Git, or from the pretests and reporting problems. Note that this kind of testing leaves a lot of false negatives: often they don't report the problems, because they try to workaround the problems themselves (they don't behave as testers and don't feel a responsibility to file bug reports when running prerelease versions; instead they'll ask for help in various fora where other users give them hints for how to workaround problems). > If not, given the expectations that you ascribe to users, there > probably should be. Probably. Don't count on me to do that work, tho. > If you are saying that *all* Emacs-23 packages and bytecode runs on > Emacs-27 then, sure, safer-load-file doesn't need to do anything. They don't all run, but they "should" all run. We know of some exceptions, and there are probably some more exceptions we don't know about, but by and large this has worked well enough (largely controlled by the amount of bug reports we receive). > A tool like safer-load-file could be told which sets of *packages* are > incompatible and warn when it sees a problem. We've had some such warnings in the past for some particular known problems, but nothing "systematic". I think the problem is a lack of motivation because in most cases the problems will be apparent soon enough that there's not much benefit to extra checks. >> > There are free opcode space available. "apply" could be added is someone >> > chooses to add it. >> I'm just pointing out differences that illustrate the fact that >> tradeoffs were quite different. > Personally I think you are ascribing too much intentionality; this could > just as easily be explained by oversight. Could be. > This still all sounds a little loose, and not fully formed. It's not fully formed at all. Otherwise I'd probably have a patch for it. Stefan