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 20:30:24 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1513992539 6834 195.159.176.226 (23 Dec 2017 01:28:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 01:28:59 +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 02:28: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 1eSYcN-0001BU-G0 for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 02:28:51 +0100 Original-Received: from localhost ([::1]:39682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSYeK-0006rR-7w for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 20:30:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSYeD-0006rL-EH for emacs-devel@gnu.org; Fri, 22 Dec 2017 20:30:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSYeC-00028y-8z for emacs-devel@gnu.org; Fri, 22 Dec 2017 20:30:45 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:40314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSYe8-00025z-Jx; Fri, 22 Dec 2017 20:30: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 vBN1UTXl023233; Fri, 22 Dec 2017 20:30:33 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id E8A57662FA; Fri, 22 Dec 2017 20:30:24 -0500 (EST) In-Reply-To: (Rocky Bernstein's message of "Fri, 22 Dec 2017 18:46:27 -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 <1773897> : uri <2555789> 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:221362 Archived-At: > If you mean always keep the source code around in the bytecode file, I'm > all for that! 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"). >> > Maybe this could be incorporated into a "safe-load-file" function. >> Define "safe" > Okay. Let me call it then "safer" then. And I will define that: detecting > problems that can be reasonably detected in advance of hitting them inste= ad > of giving a =C2=AF\_(=E3=83=84)_/=C2=AF traceback. As long as we want to support the case of using a .elc file without the corresponding .el file, some users would be very annoyed if Emacs-27 prevents them from using a file compiled with Emacs-23 just because there's a risk that you might hit an error later. > Recently have come to learn it can be worse because checks are not done on > bytecode... > Want to crash emacs immediately without a traceback? Run > emacs -batch -Q --eval '(print (#[0 "\300\207" [] 0]))' Yes, BYTE_CODE_SAFE is not safe enough, agreed. Patches welcome. > The bytecode file for cl-lib no doubt had in it "Hey, I'm emacs 24." > and I probably ran that on Emacs 25 where there was an incompatibility > that can happen between major releases. I doubt that's the problem [ cl-lib has rather unusual problems in this respect, and I suspect that you hit one of those, which don't have anything to do with the bytecode but with the fact that the cl-lib on GNU ELPA only works on Emacsen that don't come with cl-lib. It includes hacks to try and avoid the problem, but maybe you've seen people using odd configurations or older versions of GNU ELPA's cl-lib where those hacks weren't sufficiently refined. ] > If that were the case (and although probably it is not the *only* > scenario case) how much nicer would it have been if a safer-load-file > warned me about running version 24 bytecode. Do you have actual byte-code generated by Emacs-24's bytecomp.el which causes a serious error when used on more recent Emacsen? For cl-lib, the problem is not that the cl-lib compiled with Emacs-24.1 contains invalid bytecode for Emacs-27, but that for some reason that cl-lib ended up earlier in the load-path than the cl-lib that comes with Emacs-27 and it's the bundled cl-lib which should be loaded. > 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. > There may be some glibness here. The benefits of using a lower-level > general-purpose intermediate language like LLVM IR or vmgen is that becau= se > it a lower level, working with registers and pointers, understands some > structure layouts, and is more statically typed. So efficiency can be > gained by specialization. But if one doesn't break down Lisp_Object and > uses that in the same way the C interpreter currently does, then I don't > see why vmgen will be any faster than the current interpreter. (Other than > the benefit that would also be had by rewriting the interpreter without t= he > bloat and compatibility overhead) The idea is not to rewrite the same thing with vmgen, indeed. It's to design a new bytecode (which would hopefully streamline some use cases, e.g. allow processing function calls more efficiently, maybe also `apply` more efficiently, which would allow allocating closures with a single malloc of an object of size proportional to the number of free variables, ...), and while we're at it, use something like vmgen, so that we benefit from other people's efforts at improving the efficiency of the dispatch. > Thanks for the kind words. It's not something I feel all that knowledgeab= le > or qualified to do. That makes you a good person to write it. Feel free to ask questions about parts you don't understand or aren't sure. Stefan