unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Rocky Bernstein <rocky@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: A couple of things that I think should be in byte bytecode meta comments
Date: Fri, 22 Dec 2017 22:25:22 +0200	[thread overview]
Message-ID: <83h8sildcd.fsf@gnu.org> (raw)
In-Reply-To: <CANCp2gZAm3MMDsTgG4FE5V7iNWUunD7RTYDz8wg6E-NqTBZSdg@mail.gmail.com> (message from Rocky Bernstein on Fri, 22 Dec 2017 13:49:06 -0500)

> From: Rocky Bernstein <rocky@gnu.org>
> Date: Fri, 22 Dec 2017 13:49:06 -0500
> Cc: emacs-devel@gnu.org
> 
> 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). 

I guess I'm not following you.  On my system, there are 60 files whose
absolute file names end in lisp/emacs-lisp/bytecomp.el.  (And my
equivalent of your /usr/local/share/emacs is populated with files that
came from a tree which is not the stable nor the development branches.)
Some of these 60 files come from the same versions of Emacs, some from
different versions.  How can a signature that records the absolute
file name help in distinguishing between bytecomp.elc's that were
produced from the same or identical files, and those which were
produced from different, i.e. "incompatible" files?  What am I missing
here?

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

Too few to rely on, what with today's practice of installing pre-built
packages instead of building from sources on each end-user system.

> 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. 

I'm saying that the minuscule amount of times it will work will drown
in the sea of times it won't.  Worse, when it "doesn't work", it will
many times produce a false alarm: the file name is different, but the
contents was identical.  How will you distinguish between true
negatives and false negatives?  Without a means to distinguish between
them, this feature will be worse then useless: it will be an absolute
nuisance.



  reply	other threads:[~2017-12-22 20:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22 17:54 A couple of things that I think should be in byte bytecode meta comments Rocky Bernstein
2017-12-22 17:55 ` Rocky Bernstein
2017-12-22 18:30   ` Eli Zaretskii
2017-12-22 18:49     ` Rocky Bernstein
2017-12-22 20:25       ` Eli Zaretskii [this message]
2017-12-22 20:55         ` Rocky Bernstein
2017-12-23  8:25           ` Eli Zaretskii
2017-12-23  8:44             ` Rocky Bernstein
2017-12-23 15:32               ` Robert Weiner
2017-12-23 17:16                 ` Rocky Bernstein
2017-12-23 18:30                   ` Robert Weiner
2017-12-24  2:44                     ` Rocky Bernstein
2018-01-13 19:44                       ` Thien-Thi Nguyen
2017-12-22 21:27 ` Andreas Schwab
2017-12-22 21:43   ` Rocky Bernstein
2017-12-23  8:25     ` Andreas Schwab
2017-12-23  8:35       ` Rocky Bernstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h8sildcd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rocky@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).