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 15:55:06 -0500 Message-ID: References: <83o9mqlin0.fsf@gnu.org> <83h8sildcd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c06f1280b1efa0560f40840" X-Trace: blaine.gmane.org 1513976004 17237 195.159.176.226 (22 Dec 2017 20:53:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 20:53:24 +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 21:53:20 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 1eSUJj-000463-SV for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 21:53:20 +0100 Original-Received: from localhost ([::1]:38404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSULg-0000Sm-OY for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 15:55:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSULW-0000Od-Ap for emacs-devel@gnu.org; Fri, 22 Dec 2017 15:55:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSULV-0001IA-6J for emacs-devel@gnu.org; Fri, 22 Dec 2017 15:55:10 -0500 Original-Received: from mail-qk0-x230.google.com ([2607:f8b0:400d:c09::230]:46524) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eSULT-0001HK-JJ; Fri, 22 Dec 2017 15:55:07 -0500 Original-Received: by mail-qk0-x230.google.com with SMTP id b132so6193360qkc.13; Fri, 22 Dec 2017 12:55: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=Kv7bSSjwmWXFfW8H6KGNeaw8bvgWoS4zPceyLlFsRs4=; b=kFd/VSz3/YfnEfFKNPDhc9E+v1x3lqz/gFs1bZZHBFexhFsDPY4zItUmsBwsn4aHxJ GatSeW3c+OgY8+w+svLw+XyOWvZcfWhShUQEb0HWhz67RIlcEpsKu7MuNo7OvjKUNueQ q+bOdcZCgqck9WAZIvMknzVwrigzhH4nJbxph+CuWEnti8CVtZ0R7S8FEIx7tQwfmcN3 GsifhoNL+DPCGwO4At86zA6MdK6Cs9u14PIKAEQhQJPNIA/HRQ0uPfgFoAK1rl2Qzcn1 oDVXsIM6mBYwd1+X4PISJLbcavRXJxnwQHAaXu2n4CWvCHhsWR0Pt9gZhsluUkLsH287 bWwA== 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=Kv7bSSjwmWXFfW8H6KGNeaw8bvgWoS4zPceyLlFsRs4=; b=rJhXnndyHx+vfr07c6uHIX2D7xJ8dAaLw9F688b1b+HLQFMU3yyPo6C/s9u6oqwjhq lYvo0cpzwNL1n9DvFlJzJ2D+Yils5IFe2TNIt+NHRD2lk7Xr9lpMPmObw5wX1BR5IbRh Fw9cBaPfdfKvl8b+F5mDHp8ZTfdSLk+IhykJ1OTo+JYua2x9qJwc8fcCHIO+9bhEfxhs Ma2IXtA3Y271PNuR1nm9hu3STw9jbNPXbIDT5haLRTlYkO8gQBv0OFqVUotscHuYfue/ 14zc/Y2B2GChidGjyi4fUs/fiUOs/VTM/0aKBNGqa0K8WWHnitCekfBiC3dmT9PbojTv kwQw== X-Gm-Message-State: AKGB3mLxECCkoIbq+H5W1ZwmAYU+By4B5T89CWfBI5MEaVof16XWrKlV Ez1mntTm0nv3feJL/Oj4tHjOcQcBIptXvu3x5y9G6A== X-Google-Smtp-Source: ACJfBovAM9FvnFC9r+7OdPQGbJXttBiMbmUcHngSncw5LJ1XvEg3sXvXsv6OSzQkd2ObWRQLfuT/W4PhJIxK15lYnZc= X-Received: by 10.55.161.134 with SMTP id k128mr8577609qke.158.1513976106784; Fri, 22 Dec 2017 12:55:06 -0800 (PST) Original-Received: by 10.12.197.8 with HTTP; Fri, 22 Dec 2017 12:55:06 -0800 (PST) In-Reply-To: <83h8sildcd.fsf@gnu.org> X-Google-Sender-Auth: qcyZjYE8Ofm3ej41xj9Jx086rD4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::230 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:221353 Archived-At: --94eb2c06f1280b1efa0560f40840 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 22, 2017 at 3:25 PM, Eli Zaretskii wrote: > > From: Rocky Bernstein > > 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? > That there is also a SHA of the text. If the text in any of those 60 files is identical it doesn't matter for purposes of debugging and error location determination which one in the set you decide to call the source. > > 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. If that's the case, then how is this different than what we have now? 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. > Again, the SHA. --94eb2c06f1280b1efa0560f40840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 22, 2017 at 3:25 PM, Eli Zaretskii <eliz@gnu.org>= wrote:
> From: Rocky Bernstein <rocky@gnu.org>
> Date: Fri, 22 Dec 2017 13:49:06 -0500
> Cc: emacs-dev= el@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 pat= h and that may be helpful.
>
> Consider cases where I have a stable and development branch and then i= nstall 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.=C2=A0 On my system, there are 60 = files whose
absolute file names end in lisp/emacs-lisp/bytecomp.el.=C2=A0 (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.=C2=A0 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?=C2=A0 What am= I missing
here?

That there is also a SHA of=C2=A0= the text. If the text in any of those 60 files is identical it doesn't= matter for purposes of debugging and error location determination which on= e
in the set you decide to call the source.



> 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 me= an it will be totally meaningless all the time.
> And I prefer "sometimes useful" to no information, however a= ccurate that is.

I'm saying that the minuscule amount of times it will work will = drown
in the sea of times it won't.=C2=A0 Worse, when it "doesn't wo= rk", it will
many times produce a false alarm: the file name is different, but the
contents was identical.=C2=A0

If that's= the case, then how is this different than what we have now?

How will you distinguish between= true
negatives and false negatives?=C2=A0 Without a means to distinguish between=
them, this feature will be worse then useless: it will be an absolute
nuisance.

Again, the SHA.
=C2=A0

--94eb2c06f1280b1efa0560f40840--