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: Sat, 23 Dec 2017 12:16:14 -0500 Message-ID: References: <83o9mqlin0.fsf@gnu.org> <83h8sildcd.fsf@gnu.org> <83fu81luke.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0c98a82eaa14056105176b" X-Trace: blaine.gmane.org 1514049282 22755 195.159.176.226 (23 Dec 2017 17:14:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 17:14:42 +0000 (UTC) Cc: emacs-devel To: rswgnu@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 23 18:14:37 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 1eSnNZ-00059g-Fo for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 18:14:33 +0100 Original-Received: from localhost ([::1]:55580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSnPU-0007du-CE for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 12:16:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSnPH-0007bn-VB for emacs-devel@gnu.org; Sat, 23 Dec 2017 12:16:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSnPE-0003gO-4g for emacs-devel@gnu.org; Sat, 23 Dec 2017 12:16:19 -0500 Original-Received: from mail-qt0-x229.google.com ([2607:f8b0:400d:c0d::229]:35223) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eSnPD-0003fm-PN for emacs-devel@gnu.org; Sat, 23 Dec 2017 12:16:15 -0500 Original-Received: by mail-qt0-x229.google.com with SMTP id u10so39589576qtg.2 for ; Sat, 23 Dec 2017 09:16:15 -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=3/nc9Q2r1DvZiCK6BAh6qkkorpkpmydxDrE8lpLV2Y4=; b=U66ucaXVYrgfkrJL5PBXPRGqELm5GaDfjlko7txks/cWj1vyVtRLRjNA8dlZXhjnvQ zQC0gHT8jNjjmMKWUCXFgyQpGF+b3je6A3IpStLmWamTGNSTBBjCATcGSQaDn9gYvBax yvDpOsdBst+QmxDa8iBGd1ZA3PaTOph2R22PMqjOuKYv0rLmq93d/Jq/eKtEh7UWAb8/ gUdUrUGNyBnYJ/ynyH44V8ubx4kHYZ8YovllO6CtfAm6NAtTmpGw2cGNs165IGFI8IUc Jp43VL3MudohSzWUgnLRdQJM+rWAg3F84wnC7HNfpxxUSYfDd97Kc/tYbR6DNxmEvp/H T41Q== 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=3/nc9Q2r1DvZiCK6BAh6qkkorpkpmydxDrE8lpLV2Y4=; b=ThwqsGnBZGL7975yqcBrH9P3fGw1uRoQHHas40lsInd9J9mQVZxsI1agJGdpIEfjyr eclKyq/++O2llGDZb1mCXOrenS3vnjhWTGi3gaKO8ROLM64t6I3cUB2ORn/SGuz6oQqh 9kZervUBWG2O+kpbbmDMiSN3ogXAcXw6+iY9zIxky3o89MPYlCThXiNMy4Dxth4CdHIN 2OEpwJ+Hb+W86+XO2EsQoTGRTM8kymweYh7+SHS5R2pRkHddJXWLAg/zAQbaph8Pmpen wAkiiWD2kXVF3R0qru/p9QqCSRTaSM1rZopx7ZEtWtvDtm08VUOSnbfFI+mYQQwktUaI vAZQ== X-Gm-Message-State: AKGB3mIpN6OiNo1C6Zu2+32x1Gjxr3bYe+UgzROgqU+VbTmfwnt1EGSl R26HlzB5pnTOLXBqXGnwByspbgoZPn9UkAqF03Y= X-Google-Smtp-Source: ACJfBovJlVU8JbRaHLLMsGWu1b+k030TqHDdWeivJhrCR0h5L9wP/kS4LEp/T++Gex1Gwc1ccpQcaSHmFQKT1OOWdSQ= X-Received: by 10.237.48.47 with SMTP id 44mr25996084qte.283.1514049375216; Sat, 23 Dec 2017 09:16:15 -0800 (PST) Original-Received: by 10.12.197.8 with HTTP; Sat, 23 Dec 2017 09:16:14 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: FUbAkme5P3Eo65urcoIo_Y6_f4Q X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::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:221392 Archived-At: --94eb2c0c98a82eaa14056105176b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 23, 2017 at 10:32 AM, Robert Weiner wrote: > On Sat, Dec 23, 2017 at 3:44 AM, Rocky Bernstein wrote: > >> >> Path names give you good places to start looking for the file. >> >> And often they can quickly give information as to what's up, e.g. I am >> running from the stable or development branch. Or running from an Ubunt= u >> build or a source-code build. >> > > =E2=80=8BIf you are actually running a branch of Emacs and using a .elc f= ile > included therein, then =E2=80=8Byour load-path should be configured to ta= ke you to > the proper associated source file with the find-library command, unless > filenames are duplicated within the lisp tree. Only uses outside of that= , > i.e. working on files outside of the branch you are running, would this b= e > an issue, I would think, or if there ever is a bundled format of .elc tha= t > combines the byte-compiled output of multiple files. > > If anything of this nature is ever done, it should be based on the source > file's default installed location relative to the Emacs root directory fo= r > portability. Any reasonable function/tool could then find the source fil= e. > > Bob > > Let's back up a little. A function like byte-compile-file which is what would store this information into the bytecode file only has the path it is given. There are only two possible kinds of paths I know of: relative or absolute. You have most forcefully convinced yourself that the only sane way that programmers or that programs written by programmers work would be to use relative paths. It matters not because, as I said, the function has only what is given it. 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 bytecode file as well. In my experience in working in debugging, debuggers and in showing where errors are, sometimes the absolute path can be useful in addition to the relative path, for informative purposes. I 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 who 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 not mine, which so far has not caused such havoc, and I even find mildly interesting). Ok. this was a just suggestion. That it has caused such negative reaction, I've seen before in other venues, and I'm sorry. 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. --94eb2c0c98a82eaa14056105176b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 23, 2017 at 10:32 AM, Robert Weiner <<= a href=3D"mailto:rsw@gnu.org" target=3D"_blank">rsw@gnu.org> = wrote:
On Sat, Dec = 23, 2017 at 3:44 AM, Rocky Bernstein <rocky@gnu.org> wrote:

Path names give you good places to start looking for the file= .

And often they can quickly give information as to what's up, e.g. I am=20 running=C2=A0 from the stable or development branch. Or running from an=20 Ubuntu build or a source-code build.

=E2=80=8BIf you are = actually running a branch of Emacs and using a .elc file included therein, = then =E2=80=8Byour load-path should be configured to take you to the proper= associated source file with the find-library command, unless filenames are= duplicated within the lisp tree.=C2=A0 Only uses outside of that, i.e. wor= king on files outside of the branch you are running, would this be an issue= , I would think, or if there ever is a bundled format of .elc that combines= the byte-compiled output of multiple files.

If anything of this nature is ever done, it should be based on the sour= ce file's default installed location relative to the Emacs root directo= ry for portability.=C2=A0 Any reasonable function/tool could then find the = source file.

=
Bob

<= br>

Let's back up a little. A function like by= te-compile-file which is what would store this information into the bytecod= e file only has the path it is given. There are only two possible kinds of = paths I know of: relative or absolute.

You ha= ve most forcefully convinced yourself that the only sane way that=20 programmers or that=C2=A0 programs written by programmers work would be to = use=20 relative paths. It matters not because, as I said, the function has only wh= at is given it.

My suggestion was that when a= relative path is given, (which is always in your world), also turn that in= to an absolute path and store in the bytecode file as well.=C2=A0 In my exp= erience in working in debugging, debuggers and in showing where errors are,= sometimes the absolute path can be useful in addition to the relative path= , for informative purposes.=C2=A0

I know othe= rs will not believe that, and furthermore claim most emphatically that were= these paths included as meta comments=C2=A0 in the bytecode file, that wou= ld be either useless, confusing and harmful and who knows what other bad th= ings could happen.=C2=A0 (By the way, as something similar, when I enter Em= acs, I am shown a build string for a system is not mine, which so far has n= ot caused such havoc, and I even find mildly interesting).
<= br>
Ok. this was a just suggestion. That it has caused such negat= ive reaction, I've seen before in other venues, and I'm sorry.
=

For my part, I know what I can do to handle my co= ncerns when or if I decide to improve the error reporting and debugging sit= uation on Emacs. Yes, I am sorry I didn't say at the outset that this i= s were I envision this getting used.






--94eb2c0c98a82eaa14056105176b--