From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 8PhRKalufGQDzgAASxT56A (envelope-from ) for ; Sun, 04 Jun 2023 12:59:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WMRQKalufGRDAQEA9RJhRA (envelope-from ) for ; Sun, 04 Jun 2023 12:59:53 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 464D86CD3 for ; Sun, 4 Jun 2023 12:59:53 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q5lRn-0000L2-9Y; Sun, 04 Jun 2023 06:58:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5lRl-0000Kt-J3 for emacs-orgmode@gnu.org; Sun, 04 Jun 2023 06:58:53 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5lRi-0002wC-NZ for emacs-orgmode@gnu.org; Sun, 04 Jun 2023 06:58:52 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1q5lRe-00015D-Jr for emacs-orgmode@gnu.org; Sun, 04 Jun 2023 12:58:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el Date: Sun, 4 Jun 2023 17:58:37 +0700 Message-ID: References: <874juewk4k.fsf@kyleam.com> <87r0xi5jx7.fsf@gnu.org> <87o7obn0dp.fsf@localhost> <877cuzmreg.fsf@localhost> <87ile5o3vb.fsf@localhost> <878rezn087.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US In-Reply-To: <878rezn087.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.091, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1685876393; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=fZpDaxUGCzk+ZdRkWcfgrJO9iizcdJ6fgWZ1Z/gG/ig=; b=TZMThNfbMQrkc11QNbJ7Cw6Ws+4uAtva1WGz57W4cXDTa+/Ph+ulelfiSFQOV23ru8Kp9D GKtBYht97257nwDX9rK6fYLXoTRhu+4ue4yi2GcudfXajbaATS4B99NsVR2UkLWjru/VYL X+0cwOaVlqu6aR0zI4UDCbC+0ZD2uknJ1+OyDHbaKHejAuqMVdz597YyrjY3K32cSKG+qC zyvpvS3fzfFZ66u4rAxcP1mKb6k5xrJfyDnZWc0LC+ndCw+P6/Kdmx5tt1qOnvS+ikGLdA eIpROJk7keLXjsrNVl8oZTECzQgp/N7iEkP7+r6jNrzHOexzI+/poFSA0BOYAA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1685876393; a=rsa-sha256; cv=none; b=SL592i973coz9+WKqY1trQ37PsrN7VNspo4q6tvDTY5cS9VbW8JWK4vLQGd4hMfy3FjNVY PkkCSuSI2YczJPHGLufVge3WyzyPEmMzGWBbE90jS2LQxXVWc9cBVCaW9Twb1W5GCnVKzN KUOQ5knmRReeP6Qrv7ONVPICWkjz6mlBqeKiTg+6TMlfZtb3dD9IzhC+4P2SBL5cnFt1+q rfjE3FtoTRQoIxVdLBg48Hwp0cJz0lRSVAYoGUtKcbiYS9kdMTgPrCF27QCkIVCgBeyuFD yH0RC5IrC8+GR8Dxs89WFbt5RZY+037oTlYCIN5E13dIEcXTczFRjrOX3rvGhg== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -0.88 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 464D86CD3 X-Spam-Score: -0.88 X-TUID: I883SZiVdIGZ On 10/04/2023 23:58, Ihor Radchenko wrote: > Max Nikulin writes: >> Currently I do not understand: >> - Why presence of .el files in the same directory (old Org version) with >> .elc files affects result of compilation (at least for Emacs-28)? > > I may be missing your point, but `load-prefer-newer' maybe? I mean installing ELPA Org package to Emacs < 29 when another Org version is loaded. The result is different when Emacs is running from source tree (raw org .el sources are available) or from install tree (lisp files are compressed to .el.gz). In the former case Org is compiled correctly. In the latter case compressed sources causes mixed-compilation issue with following failures to load Org. I think, it is a reason why you were unable to reproduce mixed-compilation issue on Gentoo. The following commit https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9dfd945a2c2 Fix byte compilation of package built-ins https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49708 (no discussion in the bug report) introduced `package--reload-previously-loaded` instead of `package--reload-previously-loaded` and `package--list-loaded-files' (A side note. I missed a public function that reloads subset of files from a given directory that are present in `load-path' to use it in `org-reload'). `package--list-of-conflicts' had a couple of bugs: 1. Looking up for loaded earlier files, composition of `file-name-sans-extension` and `find-library-name' strips just `.gz', not `.el.gz' thus comparing e.g. '//org.el' (.gz stripped) and '//org' (.elc stripped). As a result new .el Org files are not reloaded over Org .elc files from an older version. 2. A debian-specific issue when elpa-org deb package is installed: ls -l /usr/share/emacs/site-lisp/elpa/org-9.3.1/org.* lrwxrwxrwx 1 root root 53 Jan 29 2021 /usr/share/emacs/site-lisp/elpa/org-9.3.1/org.el -> /usr/share/emacs/site-lisp/elpa-src/org-9.3.1//org.el -rw-r--r-- 1 root root 710150 Jan 29 2021 /usr/share/emacs/site-lisp/elpa/org-9.3.1/org.elc Notice that .el files are symlinks to another directory. Due to `file-truename' in `package--list-of-conflicts' .el files are not reloaded because full paths are compared. So prior to version 29, Emacs had code that is intended to reload earlier loaded files when ELPA package is installed, but it was buggy. It seems both issues are fixed in new `package--reload-previously-loaded'. Now I understand what happens, but I have not figure out what is the best strategy to prevent failures. Of course, it should be clearly stated in the manual and in the README that Org should not be loaded yet when `package-install' is called. >> - Why even when the `org-assert-version' macro is defined, an error is >> signaled on attempt to load a compiled file with unexpanded >> (org-assert-version) call (a file compiled with warning "the function >> ‘org-assert-version’ is not known")? > > This is because `org-assert-version' was not defined in Emacs during > compile time. During compilation, Emacs produces byte code calling a > function. AFAIU, the byte code is equivalent to > (funcall #'org-assert-version), which fails with error (try it with M-:). You are right. I did not realized that actually 2 kinds of errors happens: - Invalid function: org-assert-version - Symbol’s function definition is void: org-assert-version (and compile Warning: the function ‘org-assert-version’ is not known to be defined. "void"/"not known" happens when old org-macs.el is loaded. "Invalid function" is the sign of mixed compilation. `org-assert-version' is defined, but it is a macro, so can not be called during loading of an .elc file since it was not expanded during compilation. So `fboundp' is not the correct way to generate meaningful message during loading result of mixed compilation. `macrop' is more selective (and `functionp' as well). Relevant section of the elisp manual - (info "(elisp) Function Cells") - (info "(elisp) Calling Functions") - (info "(elisp) What Is a Function")