From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Bytecode interoperability: the good and bad Date: Fri, 22 Dec 2017 05:51:51 -0500 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c06f128b0b57d0560eb9afd" X-Trace: blaine.gmane.org 1513939803 4622 195.159.176.226 (22 Dec 2017 10:50:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 10:50:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 22 11:49:59 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 1eSKtr-0000uu-2K for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 11:49:59 +0100 Original-Received: from localhost ([::1]:44537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSKvp-0001aq-Gq for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 05:52:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSKvj-0001a2-0q for emacs-devel@gnu.org; Fri, 22 Dec 2017 05:51:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSKvi-0004gd-1Y for emacs-devel@gnu.org; Fri, 22 Dec 2017 05:51:55 -0500 Original-Received: from mail-qk0-x236.google.com ([2607:f8b0:400d:c09::236]:34879) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eSKvh-0004gI-SL for emacs-devel@gnu.org; Fri, 22 Dec 2017 05:51:53 -0500 Original-Received: by mail-qk0-x236.google.com with SMTP id 143so19582337qki.2 for ; Fri, 22 Dec 2017 02:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Xir3B3eJNTELK3H1ykwVU+m70hhRq81LJupDlMaio84=; b=HJdOx3oTsWqLYA5glO9xF3dlmIZSY/kA6fOoCVQneET83j70gbRT0de5cF1ce4jz7h VpS5299pkLH7GWEO8vJWz67VzB8+vYXGfVlNaJwpI84AEqqVO4T1mFVmLmEqrgOXjo1z YnvlTC3r37uLqxGvdA0kZzrpYf4o4lxFG8u//QBJ8RoakolqvKtpMEqeZpd7cxyNGj6P mEw0ZTk+Mkb+3tNdnb5FX6X6206FU/HZRZ6ivbdkDIJOC7w9M93RbdhAPYpl4p2QmsKu m3LYYQPyV55NM2AUIDJgA/j+bCR9hGjJsYFuM/HwWVWf1Ft7vDAjPW8jh9AUiOGgcK3+ omCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Xir3B3eJNTELK3H1ykwVU+m70hhRq81LJupDlMaio84=; b=Mm2YId5zpB3mFyFArXLs4chIBLCpRZw4fhYAV0gsUzm7j8sk8e1+hqcwNW6fwaHgdr 6BkEY7hwnoN+/I1PyfXeBGOBdBiPr/jXRJ0jEhIb8nvPtX+STk66QHZ876oYmOhGrer8 ooKgrR0MrHGxJONt1m4jUQAaL+xZwtGQSG5ZEoZN89dsTWZwx9JdHQoptE3l1OXSoGZb FOhDDbJxcm6rHB+cF4rD6DCLlSH13EFR9dsvT2FUhXTx1LBQDmtajF7awfPBh1Ry1m+I edBoWQwzGHTNjCT700mIY9Jw4GTqT9Gt924jWumyQQGRM+zkHzk9TIrt1SMdc4/4tnkD bHsw== X-Gm-Message-State: AKGB3mJIzhIJ6rvf7w7Goyc6oEY2AxUFUXELUvvCAq4KKAKCWRpMIegg hRkH2Dt4Skc0rcZpYUGJHtXT3rlsI1c5gCpU0FlXfg65 X-Google-Smtp-Source: ACJfBotwgOBWzULXG7+oG+PHvozd9eX+UBa514oTr8C8DjaAy6pYrH+I6HJhAwmJAmUVFupdLF/+pmqrmp4dUiqkNE0= X-Received: by 10.55.161.134 with SMTP id k128mr6072648qke.158.1513939912404; Fri, 22 Dec 2017 02:51:52 -0800 (PST) Original-Received: by 10.12.197.8 with HTTP; Fri, 22 Dec 2017 02:51:51 -0800 (PST) X-Google-Sender-Auth: e6aEiBvOFuREhgIK91i0c3gaBdU X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::236 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:221332 Archived-At: --94eb2c06f128b0b57d0560eb9afd Content-Type: text/plain; charset="UTF-8" In documenting the ELisp Bytcode format and the compilation process, I have a question. In what I am calling a "Bytecode Function Literal" -- the vector of 4-6 objects that contains the parameter list, bytecode instructions, max stack, constants vector, docstring , and interactive specification - there is no notion of what bytecode version is in effect. (Is there a better term for Bytecode Function Literal?) The next larger kind of grouping of code is a bytecode file. A bytecode file does contain a comment indicating the version of Emacs that was used in compilation is recorded. However I am not sure that fact is made use of such as to decide if a bytecode file can be run or not. I have been able to run bytecode compiled in Emacs 25 on Emacs 24 and vice versa, I think using load-file. Is there a determination made in advance of whether a bytecode file compatible with the current version of Emacs in effect? If so, how is that done? This is probably obvious, but I'll mention it anyway. The good side of allowing bytecode across different releases of Emacs is that it allows one to run bytecode from older and newer versions interoperably - when it works. And that's the rub. Unless there is some check made, you don't know if it will work. The program could crash, or worse do something unintended. In other kinds of bytecode such as the one for C Python, a bytecode version number is stored in the bytecode file. When there is a change to the bytecode, that number is changed. How does this work in Emacs Lisp? Thanks. --94eb2c06f128b0b57d0560eb9afd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In documenting the ELisp Bytcode format and the compi= lation process, I have a question.

In what I am calling = a "Bytecode Function Literal" -- the vector of 4-6 objects that c= ontains the parameter list, bytecode instructions, max stack, constants vec= tor, docstring , and interactive specification -=C2=A0 there is no notion o= f what bytecode version is in effect.

(Is the= re a better term for Bytecode Function Literal?)

=C2=A0The next larger kind of grouping of code is a bytecode file. A byt= ecode file does contain a comment indicating the version of Emacs that was = used in compilation is recorded. However I am not sure that fact is made us= e of such as to decide if a bytecode file can be run or not.

=
I have been able to run bytecode compiled in Emacs 25 on Emacs 2= 4 and vice versa, I think using load-file.

Is = there a determination made in advance of whether a bytecode file=C2=A0 comp= atible with the current version of Emacs in effect? If so, how is that done= ?

This is probably obvious, but I'll= mention it anyway. The good side of allowing bytecode across different rel= eases of Emacs is that it allows one to run bytecode from older and newer v= ersions interoperably - when it works. And that's the rub. Unless there= is some check made, you don't know if it will work. The program could = crash, or worse do something unintended.

In o= ther kinds of bytecode such as the one for C Python, a bytecode version num= ber is stored in the bytecode file. When there is a change to the bytecode,= that number is changed.

How does this work i= n Emacs Lisp?

Thanks.


<= /div>
--94eb2c06f128b0b57d0560eb9afd--