From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: How does one find out what file a library has been loaded from? Date: Sun, 24 Jul 2022 11:27:56 +0000 Message-ID: References: <83sfmxm79z.fsf@gnu.org> <83fsiwncem.fsf@gnu.org> <83mtd3ngcw.fsf@gnu.org> <838rommjxj.fsf@gnu.org> <83k084i1ed.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14538"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 24 13:29:00 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFZn9-0003ZT-Nk for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 13:28:59 +0200 Original-Received: from localhost ([::1]:45154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFZn8-0004il-GK for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 07:28:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48594) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFZmS-0003pr-3K for emacs-devel@gnu.org; Sun, 24 Jul 2022 07:28:16 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:57411 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oFZmP-00086T-EQ for emacs-devel@gnu.org; Sun, 24 Jul 2022 07:28:15 -0400 Original-Received: (qmail 87942 invoked by uid 3782); 24 Jul 2022 11:27:57 -0000 Original-Received: from acm.muc.de (p4fe15ea8.dip0.t-ipconnect.de [79.225.94.168]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 24 Jul 2022 13:27:56 +0200 Original-Received: (qmail 7570 invoked by uid 1000); 24 Jul 2022 11:27:56 -0000 Content-Disposition: inline In-Reply-To: <83k084i1ed.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292575 Archived-At: Hello, Eli. On Sat, Jul 23, 2022 at 13:11:54 +0300, Eli Zaretskii wrote: > > Date: Thu, 21 Jul 2022 20:39:48 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > > > +This function returns a file name associated with the file that > > > > > > +defined @var{symbol} (@pxref{eln files}). If @var{type} is > > > > > > +@code{nil}, then any kind of definition is acceptable. If @var{type} > > > > > > +is @code{defun}, @code{defvar}, or @code{defface}, that specifies > > > > > > +function definition, variable definition, or face definition only. > > > > > This change is for the worse: it introduces a vague and confusing > > > > > notion of "file name associated with the file that defines" a symbol. > > > > > This should be removed from the patch, as it doesn't add any useful > > > > > information, just muddies the waters. > > > > It's accurate, though. > > > No, it isn't accurate, because it doesn't say anything definitive. > > It says (or implies) there is nothing definitive to say. > But that is not true. The original text says something definitive and > useful. Adding information to it should NOT lose any of the > information that was there to begin with, because that information > still correct and not obsolete. I just don't understand you saying that the information is still correct. In about "half" the cases, when a .eln file has been loaded, the current text in the Elisp manual and load-history doc string is no longer correct. The file given in load-history is not the file that was loaded into Emacs. > > I think it says as much as you can say about the connection between the > > name of the loaded file and the file name recorded in load-history in a > > single sentence. > It is never a good thing to say "as much as you can say" if it leaves > the reader less wise. It is proving difficult to amend that text to make it accurate, while not confusing its reader. > > > What exactly did you want to say here, and why? (See, I didn't even > > > understand you intention, from reading that text.) > > That there exists such a relationship between the file and the recorded > > file name, but avoiding the falsehood that the file name is (in general) > > the name of that file. > Then TRT is to say what happens normally, and then add the description > of what happens in exceptional cases, including the description of > when the exceptions happen. We don't have exceptional cases here. We have two normal cases, one where we load a .elc file, the other where we load a .eln file. I think both somehow have to be described as normal cases. > > As an example there is a relationship between > > (i) > > /home/acm/emacs/emacs.git/sub-master-5/lisp/progmodes/cc-engine.elc, > > the file name recorded in load-history; > > and > > (ii) > > "/home/acm/.emacs.d/eln-cache/29.0.50-850ec122/cc-engine-fae36ae5-5d7a60de.eln", > > the loaded file > What does symbol-file has to do with any such "relationship"? All you > want to _add_ is that in an Emacs with native-compilation, loading a > .elc file can eventually load the corresponding .eln file instead. So > why not just say that? Maybe I'll try that. One reason not to say it is that we intend the .eln case to become the more common case, don't we? Also, we really ought to describe what /home/acm/..../cc-engine.elc _is_ in the documentation. There's no guarantee that that file exists. > > > You can describe them, and then show the example. Or fill in the > > > blanks as part of the functions' description. > > Why is giving the code snippet, as I proposed, not a good thing? > Because it uses functions not described in the manual. OK. > > Would it be better to write a new function incorporating the > > procedure, and document that? > In principle, yes. But we need to discuss first what would that > function be. See below. > > > > I've tried out this recipe and it works, but I don't yet know > > > > what these native-comp-unit functions are for, what they do in > > > > any detail, or even what a compilation-unit is. The functions > > > > are not already in the Elisp manual, and their doc strings are > > > > somewhat terse. > > I can figure out just about anything from Emacs's code (apart from the > > philosophical things), but there are only so many hours in a day. > You are splitting hair, but let me rephrase: if you cannot figure it > out in some reasonable amount of time, feel free to ask. All right. I think it would be useful to tie down the abstraction "native compilation unit". It is probably something quite simple, yet there is no "unit" in the Elisp manual index. What is a "native compilation unit"? > > > > I still think it would be a good thing to be able to get the name > > > > of an actual load file from the .elc name stored in load-history > > > > without having to go through the intermediate step of knowing a > > > > function name defined by it. > > > Did you try comp-el-to-eln-filename? > > No. How could I have known that such a function exists? > I just told you about it. I told you about it not as an accusation, > but as a way to help you find the best way of solving your problem. OK, thanks. But I still don't think I could have found out the existence of this function without asing "are there any relevant functions/variables to what I'm trying to do?". > > It generates file names which might not name existing files. It > > doesn't seem ideal for the purpose. > Then I think you should describe the purpose better and in more > detail. I simply wish to know the file from which a function has been loaded, or the loaded file corresponding to some source file. I would like to know whether this file is a source file, a .elc, or a .eln. > What exactly are you trying to accomplish and why? There are lots of reasons I might want to know the loaded file, some of which have already come up in the thread. I might want to be sure I've built Emacs with native compilation. I might be interested in benchmarking or RAM occupancy. I might wish to firm up my mental model of my Emacs (this indeed has been the case for me). > What is the data from which you start and what is the data you want to > obtain as result? The name of a source file or function, and the name of the matching file which was loaded. > In particular, is the starting point a function or a file name? or > something else entirely? Either a function or a file name. -- Alan Mackenzie (Nuremberg, Germany).