From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: How does one find out what file a library has been loaded from? Date: Sun, 24 Jul 2022 15:16:46 +0300 Message-ID: <83y1wig0y9.fsf@gnu.org> References: <83sfmxm79z.fsf@gnu.org> <83fsiwncem.fsf@gnu.org> <83mtd3ngcw.fsf@gnu.org> <838rommjxj.fsf@gnu.org> <83k084i1ed.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40106"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 24 14:18:13 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 1oFaYm-000AFw-AR for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 14:18:12 +0200 Original-Received: from localhost ([::1]:52930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFaYk-0004CN-Vr for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 08:18:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaXP-0002HR-Ki for emacs-devel@gnu.org; Sun, 24 Jul 2022 08:16:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58222) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaXP-0007HE-6d; Sun, 24 Jul 2022 08:16:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3jDfafYogvb6TzcGklAT5CllLV9TRdKErRD3uyq1EjA=; b=R1HRFGhmPxBd 6ng06nKqdhKtyoAk7jR4nAdxG7LFRqmdT8qyXoPMiybkRMk/1ixdW+ZB+xX0HgcSO6qJZytXDynsf uWiG4XCLjIsgif5BL1Nsa3c04J73hOhAE4kDGGpbmxbaDfcolafuRTsHx1gCAWH9uULqN/AaDRN9M hHSD2nhIO3h2x3dFiDizvySpI9oxu6eS9tO+fqFHl2rfJ32yVK/Q509Gbd+oCEziZbIcLlEOsBUGO 2dk+gKA+Z8BJz0F2Dba1830IzxPn2cBVTF1rVcPcgFoG8Qm6DkgoDVhR8ovpmxfGJl0hKmQrpyV2j O9a3ohaC4+6Oi9ZwbBKohQ==; Original-Received: from [87.69.77.57] (port=2694 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaXO-0003Dx-Mj; Sun, 24 Jul 2022 08:16:47 -0400 In-Reply-To: (message from Alan Mackenzie on Sun, 24 Jul 2022 11:27:56 +0000) 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:292582 Archived-At: > Date: Sun, 24 Jul 2022 11:27:56 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > 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. Natively-compiled Lisp packages are still an exception; people are definitely less familiar with them than with the byte-compiled ones.. They might not be one day, at which time we might need to change the text, but for now they are. So describing the simple case of .elc first and the more complex .eln case afterwards sounds TRT to me. As a nice benefit, it will allow simple and clear description in both cases, with a simple logic that will not confuse the reader. > It is proving difficult to amend that text to make it accurate, while not > confusing its reader. That's my point: you don't need to amend. That text is still correct, as long as no *.eln files are involved. Just _add_ to it the description of what happens when *.eln files _are_ around. This is good methodology in manuals: describe the simple case first and the more complex one after it. Trying to describe both together usually leads to a much more complex and harder to read text. If you are still unconvinced, just leave it alone, and I will suggest the change to that text. > > 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. See above: "normal" and "exception" have slightly different meanings here. > One reason not to say it is that we intend the .eln case to become > the more common case, don't we? No need to worry about that, not yet. > 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 are saying that if the .elc file doesn't exist, load-history still names it and not the .el file instead? That's not what I see here: I see the .el files where .elc don't exist. > 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"? Let's get back to that if we decide that the code proposed by Andrea is really the best solution for this. If we decide that the best solution doesn't involve any functions that have "compilation unit" in their names, we don't need to define that term. > > > > 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. That is still too general. I suggest to describe several specific use cases in more detail, because the solutions might be different. In general, you can use load-history or symbol-file to know which file was loaded. If load-history says it was a .elc file, and the build supports native compilation, you need to see if the function was natively-compiled, using (subr-native-elisp-p (symbol-function FUNC)) where FUNC is a function's symbol. If the above returns non-nil, then comp-el-to-eln-rel-filename will produce the base name of the .eln file corresponding to a .el file. The above are the building blocks; what's left is to use them in a particular case. > I might want to be sure I've built Emacs with native compilation. Use native-comp-available-p for this.