From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: A couple of things that I think should be in byte bytecode meta comments Date: Sat, 23 Dec 2017 13:30:49 -0500 Message-ID: References: <83o9mqlin0.fsf@gnu.org> <83h8sildcd.fsf@gnu.org> <83fu81luke.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114058a4af27a80561062332" X-Trace: blaine.gmane.org 1514053819 5107 195.159.176.226 (23 Dec 2017 18:30:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 18:30:19 +0000 (UTC) Cc: emacs-devel To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 23 19:30: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 1eSoYl-0000nj-PP for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 19:30:12 +0100 Original-Received: from localhost ([::1]:34814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSoak-0004a0-3y for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 13:32:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSoZy-0004YK-UI for emacs-devel@gnu.org; Sat, 23 Dec 2017 13:31:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSoZx-0005iw-HQ for emacs-devel@gnu.org; Sat, 23 Dec 2017 13:31:26 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSoZs-0005dY-P6; Sat, 23 Dec 2017 13:31:20 -0500 Original-Received: from mail-qt0-f182.google.com ([209.85.216.182]:33397) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eSoZs-0002V5-Gb; Sat, 23 Dec 2017 13:31:20 -0500 Original-Received: by mail-qt0-f182.google.com with SMTP id e2so39732938qti.0; Sat, 23 Dec 2017 10:31:20 -0800 (PST) X-Gm-Message-State: AKGB3mKPcGok0iLA3jhhi1EdYB+8+Gn68XNDUROg/J8rPiDtQopz0ULZ 7qpM3zT9vpY+5DCGE3DOLJ4QIe0u4bsLfcQDhiI= X-Google-Smtp-Source: ACJfBosZfAL+jeF71WkAm7NjYlda86orqHdRgRP5HsCO3L3xkwUBYLrNMNDzh8h1xz5T8bGWJp+q29wwX0PWDQODq/M= X-Received: by 10.200.38.33 with SMTP id u30mr26339352qtu.197.1514053879931; Sat, 23 Dec 2017 10:31:19 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Sat, 23 Dec 2017 10:30:49 -0800 (PST) In-Reply-To: X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:221395 Archived-At: --001a114058a4af27a80561062332 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 23, 2017 at 12:16 PM, Rocky Bernstein wrote: > > My suggestion was that when a relative path is given, (which is always in > your world), also turn that into an absolute path and store in the byteco= de > file as well. > =E2=80=8BPeople are just sharing their thoughts on whether that appears to = be helpful or not. You have acknowledged that at runtime, the absolute path may be invalid, but you have not provided your use case to show where and when it might be helpful. =E2=80=8B=E2=80=8B > In my experience in working in debugging, debuggers and in showing wher= e > errors are, sometimes the absolute path can be useful in addition to the > relative path, for informative purposes. > =E2=80=8B=E2=80=8B =E2=80=8BOnly when it is accurate. But you haven't yet made a suggestion a= bout how to make absolute paths in .elc files accurate during runtime, as far as I recall. Maybe a static absolute path would provide a heuristic for finding the run-time absolute path, maybe not. You haven't shown anything either way yet. > =E2=80=8B=E2=80=8B > =E2=80=8BI know others will not believe that, and furthermore claim most > emphatically that were these paths included as meta comments in the > bytecode file, that would be either useless, confusing and harmful and wh= o > knows what other bad things could happen. (By the way, as something > similar, when I enter Emacs, I am shown a build string for a system is no= t > mine, which so far has not caused such havoc, and I even find mildly > interesting). > =E2=80=8BIt is a matter of utility, not of havoc. =E2=80=8B > =E2=80=8BOk. this was a just suggestion. That it has caused such negative > reaction, I've seen before in other venues, and I'm sorry. > =E2=80=8B=E2=80=8B > For my part, I know what I can do to handle my concerns when or if I > decide to improve the error reporting and debugging situation on Emacs. > Yes, I am sorry I didn't say at the outset that this is were I envision > this getting used. > =E2=80=8BYes, an easy to follow use case would be helpful. I am very much = in favor of improving Emacs' error messages, especially anything that leads to the source of an error when a backtrace is not produced. If you can explain how something you envision could make that happen, then you'll likely see feedback change. BTW, I think there might be a good idea in there about using hash codes to verify valid use of a file, though my personal experience is that incompatible byte codes are well reported by Emacs and have not caused me any problems to date. The much bigger problem is tracing an error raised from C code back to the source function that raised it when running without a C debugger active. Without that, users can't provide much of a bug report except possibly how to trigger the problem. Bob --001a114058a4af27a80561062332 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 23, 2= 017 at 12:16 PM, Rocky Bernstein <rocky@gnu.org>= wrote:

My suggestion was that wh= en a relative path is given, (which is always in your world), also turn tha= t into an absolute path and store in the bytecode file as well.
=

=E2=80=8BPeople are just sharing their= thoughts on whether that appears to be helpful or not.=C2=A0 You have ackn= owledged that at runtime, the absolute path may be invalid, but you have no= t provided your use case to show where and when it might be helpful.
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">
<= /div>
=E2=80=8B=E2=80=8B
=C2= =A0 In my experience in working in debugging, debuggers and in showing wher= e errors are, sometimes the absolute path can be useful in addition to the = relative path, for informative purposes.=C2=A0
=
=E2=80=8B=E2=80=8B
=E2=80=8BOnly when it is accurate.= =C2=A0 But you haven't yet made a suggestion about how to make absolute= paths in .elc files accurate during runtime, as far as I recall.
Maybe a = static absolute path would provide a heuristic for finding the run-time abs= olute path, maybe not.=C2=A0 You haven't shown anything either way yet.=
=E2=80=8B=E2=80=8B
=E2=80=8B<= span style=3D"font-family:arial,sans-serif">I know others will not believe = that, and furthermore claim most emphatically that were these paths include= d as meta comments=C2=A0 in the bytecode file, that would be either useless= , confusing and harmful and who knows what other bad things could happen.= =C2=A0 (By the way, as something similar, when I enter Emacs, I am shown a = build string for a system is not mine, which so far has not caused such hav= oc, and I even find mildly interesting).=C2=A0

=E2=80=8BIt is a matter of utility, not of = havoc.
=E2=80=8B
=E2=80=8BOk. this was a just suggestion. That it has c= aused such negative reaction, I've seen before in other venues, and I&#= 39;m sorry.=C2=A0
=E2=80=8B=E2=80=8B
For= my part, I know what I can do to handle my concerns when or if I decide to= improve the error reporting and debugging situation on Emacs. Yes, I am so= rry I didn't say at the outset that this is were I envision this gettin= g used.

=E2=80=8BYes, = an easy to follow use case would be helpful.=C2=A0 I am very much in favor = of improving Emacs' error messages, especially anything that leads to t= he source of an error when a backtrace is not produced.=C2=A0 If you can ex= plain how something you envision could make that happen, then you'll li= kely see feedback change.

BTW, I think there might be a good idea in= there about using hash codes to verify valid use of a file, though my pers= onal experience is that incompatible byte codes are well reported by Emacs = and have not caused me any problems to date.=C2=A0 The much bigger problem = is tracing an error raised from C code back to the source function that rai= sed it when running without a C debugger active.=C2=A0 Without that, users = can't provide much of a bug report except possibly how to trigger the p= roblem.

Bob


--001a114058a4af27a80561062332--