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: Re: A couple of things that I think should be in byte bytecode meta comments Date: Fri, 22 Dec 2017 13:49:06 -0500 Message-ID: References: <83o9mqlin0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114661986bd68e0560f2454b" X-Trace: blaine.gmane.org 1513968499 20700 195.159.176.226 (22 Dec 2017 18:48:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 18:48:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 22 19:48:15 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 1eSSMg-00052H-MR for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 19:48:14 +0100 Original-Received: from localhost ([::1]:33895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSSOd-0004wz-Iv for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 13:50:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSSNZ-0004vG-Tf for emacs-devel@gnu.org; Fri, 22 Dec 2017 13:49:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSSNZ-0007y7-1A for emacs-devel@gnu.org; Fri, 22 Dec 2017 13:49:09 -0500 Original-Received: from mail-qk0-x229.google.com ([2607:f8b0:400d:c09::229]:33620) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eSSNX-0007wu-G8; Fri, 22 Dec 2017 13:49:07 -0500 Original-Received: by mail-qk0-x229.google.com with SMTP id x7so18471818qkb.0; Fri, 22 Dec 2017 10:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PMrYB9vFJa/AYjrm5mLQUovAItEukKv6X1n6WVAcJPE=; b=gpF9SKcg4AV8YK9TFboWGFV8qgZJTKVTLTXZ7xgD2CKpP9nneUvhvkTs77OI8lsC3o dq5/4ZwXVenzJH9NHfGmo2YhZ+srnRko+tnVWLDH5IK+Zh3q+4ZXVPIKuIOcJScxauKV 8awc4y20v0QUdXDcDDTIorkz3ByelMWpDv5s6Vx6Oj8lU1kje8cXz7Y06BYCluPQ8PzG n4wjN0rE5WPb0tNyAjF0p1r5f+pQn9wGtd5KhZYA05AzjnqcLYQgMgDiza5iUbtgxGCU byXTBkOzD3Y3kRVLn/74Yc07U60DPG2YZv18wRnjXBAbUOvg7CiflXkKGv6aSIszFNbW uRrw== 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PMrYB9vFJa/AYjrm5mLQUovAItEukKv6X1n6WVAcJPE=; b=kthee9buMvajrf6/+hs9+PFs3rBTUW4+KIsZD5stCHWyo1mOimGMoxjws++xWvFHzM 8cNSJwL3Ju3PBpnsexgTw/23K7qE+hhEH3HlyYBaN9QF7cs6jTL9aIuY92kwsWVTsDMs PjjUNvbzALzIUkQor4dFug3S6oUgkKedrjbmSmd2GBjxFKcsYNjE/krlxHdm/n6mxxvY 0O3CFtVwE/o9UtvXHLFDBA8GGM8N4uZKVnhoqrXcCXQuHp+zs6O5NUq2X6HNrF2hbhTa vTv3DlYRtW0niLTCWhzMQ2K23tL1HlH1WhBJcNMEXURSkS/IM7MAESL+ljW8Uab4yh4r 9IKg== X-Gm-Message-State: AKGB3mLuiYM8QZTWkYMeG6r5Y5rfOSfzj+Msp89cgeK5apZD6onD4c3N psJ50uAh9iad3dGF1TBdgysXGLV3u0OUil8P3sxci77L X-Google-Smtp-Source: ACJfBotinaouVpbXUd6VgQYrCuo67TsyvmxoLdd5W2EgTl9QjOt66UQYHcUQPYQtxn2bc7Ya5nhaQhCrDarcGMh+XHs= X-Received: by 10.55.215.144 with SMTP id t16mr21581534qkt.15.1513968546599; Fri, 22 Dec 2017 10:49:06 -0800 (PST) Original-Received: by 10.12.197.8 with HTTP; Fri, 22 Dec 2017 10:49:06 -0800 (PST) In-Reply-To: <83o9mqlin0.fsf@gnu.org> X-Google-Sender-Auth: x84KaKqLyGLFVpJ4L72oaTjhyAM X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::229 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:221347 Archived-At: --001a114661986bd68e0560f2454b Content-Type: text/plain; charset="UTF-8" There is a bit of flexibility in how run-time systems handle denoting the file name. One thing that is often done is give the path as it was specified in the compile command. This could be ./byte-comp.el or ./emacs-lisp/byte-comp.el (And from this you might see where I'm going with this). One run-time system for a programming language I am familiar with started with the what I described (use path as given in invocation) and then and switched to turning everything into an absolute path. Personally, I like giving both when the starting point was indeed a relative path. Now as to the portability. Yes, if the file is run on another system, the path isn't exact. But it does give some idea of what we are talking as you git closer to the bottom of the path and that may be helpful. Consider cases where I have a stable and development branch and then install into say /usr/local/share/emacs/lisp. Even though the top-level directories are not the same, it still is useful to know where in the source code tree (whether on my system or not). And I recall one Emacs package that concatenated a bunch of bytecode files xx-a.elc xx-b.elc and called the result xx.elc. Although unusual, with the filenames in the bytecode, you can unscramble this . And finally there will be cases where the path is exact. In sum, just because sometimes it doesn't work out, doesn't mean it will be *totally *meaningless all the time. And I prefer "sometimes useful" to no information, however accurate that is. On Fri, Dec 22, 2017 at 1:30 PM, Eli Zaretskii wrote: > > From: Rocky Bernstein > > Date: Fri, 22 Dec 2017 12:55:15 -0500 > > > > I mean file path or file name, not the file contents. > > You mean, the absolute file name of the source file? But then the > byte-compiled file will be unportable, as the file name will be > different on another system. > --001a114661986bd68e0560f2454b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a bit of flexibility in how run-time systems= handle denoting the file name. One thing that is often done is give the pa= th as it was specified in the compile command. This could be ./byte-comp.el= or ./emacs-lisp/byte-comp.el=C2=A0 (And from this you might see where I= 9;m going with this).

One run-time system for a pr= ogramming language I am familiar with started with the what I described (us= e path as given in invocation) and then and switched to turning everything = into an absolute path. Personally, I like giving both when the starting poi= nt was indeed a relative path.

Now as to the p= ortability. Yes, if the file is run on another system, the path isn't e= xact. But it does give some idea of what we are talking as you git closer t= o the bottom of the path and that may be helpful.=C2=A0=C2=A0

Consider cases where I have a stable and development branc= h and then install into say /usr/local/share/emacs/lisp. Even though the to= p-level directories are not the same, it still is useful to know where in t= he source code tree (whether on my system or not).

And I recall one Emacs package that concatenated a bunch of bytecode= files xx-a.elc xx-b.elc and called the result xx.elc. Although unusual, with the=20 filenames in the bytecode, you can unscramble this .

<= div>And finally there will be cases where the path is exact.

In sum, just because sometimes it doesn't work out, doe= sn't mean it will be totally meaningless all the time. And I pre= fer "sometimes useful" to no information, however accurate that i= s.


On Fri, Dec 22, 2017 at 1:30 PM, Eli Zaretskii <eliz@gnu.org= > wrote:
> From: Rocky B= ernstein <rocky@gnu.org>
> Date: Fri, 22 Dec 2017 12:55:15 -0500
>
> I mean file path or file name, not the file contents.

You mean, the absolute file name of the source file?=C2=A0 But then = the
byte-compiled file will be unportable, as the file name will be
different on another system.

--001a114661986bd68e0560f2454b--