From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 17 14:04:00 2020 Received: (at submit) by debbugs.gnu.org; 17 Sep 2020 18:04:01 +0000 Received: from localhost ([127.0.0.1]:38980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIyGD-0004CL-Iu for submit@debbugs.gnu.org; Thu, 17 Sep 2020 14:04:00 -0400 Received: from lists.gnu.org ([209.51.188.17]:51118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIyGC-0004CD-30 for submit@debbugs.gnu.org; Thu, 17 Sep 2020 14:03:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kIyGB-0002sO-RA for bug-gnu-emacs@gnu.org; Thu, 17 Sep 2020 14:03:55 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:44669) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kIyGA-0006B3-1W for bug-gnu-emacs@gnu.org; Thu, 17 Sep 2020 14:03:55 -0400 Received: by mail-wr1-x42e.google.com with SMTP id s12so3021752wrw.11 for ; Thu, 17 Sep 2020 11:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z5UR8XFvIuOY2sVrYJyCWYdRmsD2nLjnaTIsQu+VJcU=; b=VSKTaQkkReCmEnOV3RaybuOwfhYMgKVmnLaRXeZIW6P7+smjydgDdAbnCiyr1PB71Z IpLkGWpnZHO8rHov4FANuRIqHBZrK8eDUY4DW3SXh7IWxLqvKGMaS0vWczncr2NbNQr7 lZcnYqzkqc6yyVer2sZ7JIUberFKYCr2gQq+SFvCdnZvoIvQlY9Vz8w+KvoOUh0sROqD Tz8QIzGVTEx/M6eRoDosjrwpaWoHaO7an6CXUOM4JAHWHbEB++4XdqICsng25qw/13Sc GZmmcyG/cTrNKnZ7DyXM7fkEIESAQdFHTPPpy/G8KLHrV46rG0BnbrbEzdkBLXezE7kS DCUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z5UR8XFvIuOY2sVrYJyCWYdRmsD2nLjnaTIsQu+VJcU=; b=PNfmF2cm4/1y00UQbtBHsYRQYDP+/zbmyHVYq0KpAzidRt49u+DDUQgWc9PF/UM+Zg VjpetGl0+dmmJnuUdUZHN7PeODF3XHV974wtkiv38tH0T9GqASX1mP+MUBup3k6Mw+Wb wZB3hVFbPlm8iVcRGu7hSb36PF4oKxThWGa7PqTUF/gu7FnwvZUT88U3+WpDRPB/ySmG oSytSfvpVJKAZ7rini4vvH0DQB6jtjwPB4kBhmYVZisNKjOOB9j55YJhfSqjWerozh8c j1SeSNcj8vzP7AaSKHooMvTl2JZJgLPM3bq4hchljdqgjNYALAI0yoWXJy2lFnw/GNQp j6Kg== X-Gm-Message-State: AOAM531sIUJzMwmqsjmMGE0fGske1ay4VjQhrChNnVkARSWpxpfquxEC EuFKekC2H7c6jDurd2Tb3cniQ5DltaTNfDJXYzlOXxn8zvE1ig== X-Google-Smtp-Source: ABdhPJyyCjRNxDtt5QIe3C6X1WlVIh1j6TRf8zB6zSJOyHWmVte8LHwXLl+7EPriaItahKuccOR1o+f4bb1rxA9ncS8= X-Received: by 2002:adf:fc92:: with SMTP id g18mr35857365wrr.201.1600365830919; Thu, 17 Sep 2020 11:03:50 -0700 (PDT) MIME-Version: 1.0 From: Tom Gillespie Date: Thu, 17 Sep 2020 14:03:39 -0400 Message-ID: Subject: feature/native-comp; path for .eln files when running with --no-init-file To: Emacs Bug Report , Andrea Corallo Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x42e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Andrea, Not quite a bug, but an inconsistency in the behavior of comp-eln-load-path compared to the behavior of load-path. Best! Tom While investigating the json-mode kill-buffer bug I encountered an issue which seems like it might cause confusion at some point. comp-eln-load-path is set at startup and materialized. When Emacs is launched with -q, load-path does not contain the materialized locations of paths inside user-emacs-directory until after a call to package-initialize. I think that there is a similar need for comp-eln-load-path, which is that it needs to exclude the user eln cache path when emacs is launched with -q so that it is possible to debug issues arising from stale/bad eln files. There will be a similar issue with site-lisp and -Q. I don't know whether stale files could cause a problem given how you hash to generate the names for the eln files, but I'm imagining cases where someone upgraded gcc or libgccjit and something changed. I think that not setting the user path when Emacs is run with -q is consistent with Emacs behavior for load-path. Right now a user has to explicitly pop the old eln cache directory and then update the new directory if they reset user-emacs-directory as I do in the longer reproduction for the json-mode bug (reproduced below). #+begin_src bash emacs -q \ --eval "(setq user-emacs-directory \"/tmp/test/.emacs.d/\")" \ --eval "(when (boundp 'comp-eln-load-path) (pop comp-eln-load-path) (add-to-list 'comp-eln-load-path (concat user-emacs-directory \"eln-cache\")))" #+end_src I don't have a good solution for this, but wanted to raise the issue since I anticipate that there will be quite a bit of confusion if the user eln cache continues to point to the path ~/.emacs.d/eln-cache instead of either not being set or updating to be inside user-emacs-directory the first time the value is needed. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 10 05:48:16 2020 Received: (at 43476) by debbugs.gnu.org; 10 Oct 2020 09:48:17 +0000 Received: from localhost ([127.0.0.1]:36994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRBU8-0004tz-MV for submit@debbugs.gnu.org; Sat, 10 Oct 2020 05:48:16 -0400 Received: from mab.sdf.org ([205.166.94.33]:41684 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRBU2-0004tn-R2 for 43476@debbugs.gnu.org; Sat, 10 Oct 2020 05:48:15 -0400 Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kRBU1-0007QG-EQ; Sat, 10 Oct 2020 09:48:09 +0000 From: Andrea Corallo To: Tom Gillespie Subject: Re: bug#43476: feature/native-comp; path for .eln files when running with --no-init-file Date: Sat, 10 Oct 2020 09:48:09 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 43476 Cc: 43476@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Tom Gillespie writes: > Hi Andrea, > Not quite a bug, but an inconsistency in the behavior of > comp-eln-load-path compared to the behavior of load-path. Best! > Tom > > While investigating the json-mode kill-buffer bug I encountered an > issue which seems like it might cause confusion at some point. > comp-eln-load-path is set at startup and materialized. > > When Emacs is launched with -q, load-path does not contain the > materialized locations of paths inside user-emacs-directory until > after a call to package-initialize. > > I think that there is a similar need for comp-eln-load-path, which is > that it needs to exclude the user eln cache path when emacs is > launched with -q so that it is possible to debug issues arising from > stale/bad eln files. There will be a similar issue with site-lisp and > -Q. > > I don't know whether stale files could cause a problem given how you > hash to generate the names for the eln files, but I'm imagining cases > where someone upgraded gcc or libgccjit and something changed. I think > that not setting the user path when Emacs is run with -q is consistent > with Emacs behavior for load-path. > > Right now a user has to explicitly pop the old eln cache directory and > then update the new directory if they reset user-emacs-directory as I > do in the longer reproduction for the json-mode bug (reproduced > below). > > #+begin_src bash > emacs -q \ > --eval "(setq user-emacs-directory \"/tmp/test/.emacs.d/\")" \ > --eval "(when (boundp 'comp-eln-load-path) (pop comp-eln-load-path) > (add-to-list 'comp-eln-load-path (concat user-emacs-directory \"eln-cache\")))" > #+end_src > > I don't have a good solution for this, but wanted to raise the issue > since I anticipate that there will be quite a bit of confusion if the > user eln cache continues to point to the path ~/.emacs.d/eln-cache > instead of either not being set or updating to be inside > user-emacs-directory the first time the value is needed. Hi Tom, I think the fundamental issue is that we need a eln-cache directory to operate anyway. So either we assume that eln compilation is correct and transparent (current approach) or we need to set the eln-cache directory to be in some temporary directory for every -q run. This would indeed require the recompilation a bunch of compilation units at each -q startup. I'm personally for keeping the current approach as the second one could be annoying especially on non very powerful machines. Still a power user (like you :) can decide not to trust the correctness assumption and hack it around as you have showed. As ATM I don't have any better idea on this I'd be for closing this bug unless some idea/action is suggested, what do you think about? Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 10 15:12:27 2020 Received: (at 43476) by debbugs.gnu.org; 10 Oct 2020 19:12:27 +0000 Received: from localhost ([127.0.0.1]:38537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRKI7-0006I2-03 for submit@debbugs.gnu.org; Sat, 10 Oct 2020 15:12:27 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:44975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRKI2-0006Hl-2s for 43476@debbugs.gnu.org; Sat, 10 Oct 2020 15:12:25 -0400 Received: by mail-wr1-f53.google.com with SMTP id t9so13936996wrq.11 for <43476@debbugs.gnu.org>; Sat, 10 Oct 2020 12:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yNBo5EdbcLRdmAS+++bpt/8oYQpGz9/TTpFHLEOeCjo=; b=rezGojFNYorYYzcwPbLixFDAKtueWOs3FbiAzUwj62394ES3LBdZVjs4Q6vdrpsRes vZ/qWLlSkRqDmnNc9h1Ef6QfqAXnzDFBd7qaymC66B8d6t0LK2neTERxFjkpE1BR+RqI N0bm8QSuFFpZ9Kh1GkswEDbVDfyigI5k/x1k+qn1eURU7gXjt7JYdE/FSBTpjQsz1IU6 A14gr3H8h2qC7haSjad9trHNYVRG4nIFQ8vv/9bnDZ3sckL4t5xGib5RGm8WR5uGHjuV 8/awi0akmlAYGAXVJYdmO7TTkhxJBbSHDrpGh7QLZ8YkNBnHJWbRWqzyo1YWsIBTo8yx +g9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yNBo5EdbcLRdmAS+++bpt/8oYQpGz9/TTpFHLEOeCjo=; b=riVbZPD156eeGiXiWlw8qDql9oARE4/kgABwS1uFaHLaDbhRDnAG0v4G6sq8uWoul2 XeRkh9/s3TFChayyDGclsYfbRJdbHsCt2B8/KBhw8PDv1chxTeuGLKq9rxu88uJXlAMK zEnTsJ0VCA2trGWxSCCHQhPG343+KRejYb9EaxUE73+DjAlmzuQ1ZncTEj/Z3xwzuMQV zYQtSy76P0muLmzHzgc2sBI/t6SO9dek+b22Ue4W5llOTAm+ctU0ncBXOIpOY+z2FHbf L23yPP+SVdojQLXqpjJdF5nK/eOFKLSjheojHDSDJYhgLbXaydPkbvjyE6+HweoE8qVR xWmQ== X-Gm-Message-State: AOAM531PoCRclOqNROJedM46UC7e/s3ffKvKYGmhmE4SlGbONpFNbhO6 xd0lXLl4Izlr7LmD6wslyWaTLC0r/GJsxPHakSs= X-Google-Smtp-Source: ABdhPJx3pQJUm4FZ9AZChHgNArqiFc6/1UljpjFEIoKEHnM1/zNza8Ihc1KWeOQUiWbGB9lLOOK1Lp71LjTlWGGsd6M= X-Received: by 2002:adf:a345:: with SMTP id d5mr22996158wrb.55.1602357136166; Sat, 10 Oct 2020 12:12:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Gillespie Date: Sat, 10 Oct 2020 15:12:05 -0400 Message-ID: Subject: Re: bug#43476: feature/native-comp; path for .eln files when running with --no-init-file To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 43476 Cc: 43476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Andrea, I think it is ok to close this. I don't see an easy solution here. My workaround works, and the way that the eln files are named seems like it is safe against most common issues (I have no idea what the effect of changing versions of libgccjit would actually be, it was just a hypothetical). I think the only practical thing that could be done is to add a note to the manual about how to change the location of the eln-cache at startup. Otherwise, this bug can serve as a record in case anyone encounters an issue. Best! Tom On Sat, Oct 10, 2020 at 5:48 AM Andrea Corallo wrote: > > Tom Gillespie writes: > > > Hi Andrea, > > Not quite a bug, but an inconsistency in the behavior of > > comp-eln-load-path compared to the behavior of load-path. Best! > > Tom > > > > While investigating the json-mode kill-buffer bug I encountered an > > issue which seems like it might cause confusion at some point. > > comp-eln-load-path is set at startup and materialized. > > > > When Emacs is launched with -q, load-path does not contain the > > materialized locations of paths inside user-emacs-directory until > > after a call to package-initialize. > > > > I think that there is a similar need for comp-eln-load-path, which is > > that it needs to exclude the user eln cache path when emacs is > > launched with -q so that it is possible to debug issues arising from > > stale/bad eln files. There will be a similar issue with site-lisp and > > -Q. > > > > I don't know whether stale files could cause a problem given how you > > hash to generate the names for the eln files, but I'm imagining cases > > where someone upgraded gcc or libgccjit and something changed. I think > > that not setting the user path when Emacs is run with -q is consistent > > with Emacs behavior for load-path. > > > > Right now a user has to explicitly pop the old eln cache directory and > > then update the new directory if they reset user-emacs-directory as I > > do in the longer reproduction for the json-mode bug (reproduced > > below). > > > > #+begin_src bash > > emacs -q \ > > --eval "(setq user-emacs-directory \"/tmp/test/.emacs.d/\")" \ > > --eval "(when (boundp 'comp-eln-load-path) (pop comp-eln-load-path) > > (add-to-list 'comp-eln-load-path (concat user-emacs-directory \"eln-cache\")))" > > #+end_src > > > > I don't have a good solution for this, but wanted to raise the issue > > since I anticipate that there will be quite a bit of confusion if the > > user eln cache continues to point to the path ~/.emacs.d/eln-cache > > instead of either not being set or updating to be inside > > user-emacs-directory the first time the value is needed. > > Hi Tom, > > I think the fundamental issue is that we need a eln-cache directory to > operate anyway. So either we assume that eln compilation is correct and > transparent (current approach) or we need to set the eln-cache directory > to be in some temporary directory for every -q run. This would indeed > require the recompilation a bunch of compilation units at each -q > startup. > > I'm personally for keeping the current approach as the second one could > be annoying especially on non very powerful machines. Still a power > user (like you :) can decide not to trust the correctness assumption and > hack it around as you have showed. > > As ATM I don't have any better idea on this I'd be for closing this bug > unless some idea/action is suggested, what do you think about? > > Thanks > > Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 10 15:22:52 2020 Received: (at 43476-done) by debbugs.gnu.org; 10 Oct 2020 19:22:52 +0000 Received: from localhost ([127.0.0.1]:38555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRKSC-0006Yi-2n for submit@debbugs.gnu.org; Sat, 10 Oct 2020 15:22:52 -0400 Received: from mab.sdf.org ([205.166.94.33]:46670 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kRKS9-0006YT-71 for 43476-done@debbugs.gnu.org; Sat, 10 Oct 2020 15:22:50 -0400 Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kRKS6-00011G-D0; Sat, 10 Oct 2020 19:22:46 +0000 From: Andrea Corallo To: Tom Gillespie Subject: Re: bug#43476: feature/native-comp; path for .eln files when running with --no-init-file References: Date: Sat, 10 Oct 2020 19:22:46 +0000 In-Reply-To: (Tom Gillespie's message of "Sat, 10 Oct 2020 15:12:05 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 43476-done Cc: 43476-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Tom Gillespie writes: > Hi Andrea, > I think it is ok to close this. I don't see an easy solution here. > My workaround works, and the way that the eln files are named seems > like it is safe against most common issues (I have no idea what the > effect of changing versions of libgccjit would actually be, it was > just a hypothetical). I think the only practical thing that could be > done is to add a note to the manual about how to change the location > of the eln-cache at startup. I agree this is something we'll have to mention. closing, thanks! Andrea From unknown Tue Aug 19 14:23:59 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 08 Nov 2020 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator