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: Suppressing native compilation (short and long term) Date: Fri, 07 Oct 2022 15:40:53 +0300 Message-ID: <83zge7n6wa.fsf@gnu.org> References: <837d1gvt35.fsf@gnu.org> <87sfk3yl10.fsf@yahoo.com> <87o7uqtlsl.fsf@yahoo.com> <83sfk2rzjs.fsf@gnu.org> <87k05du6x0.fsf@yahoo.com> <83tu4hqxp8.fsf@gnu.org> <87ilkxs9yg.fsf@yahoo.com> <83czb5qsyk.fsf@gnu.org> <8335c1qmy3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2736"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 07 16:54:31 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 1ogokA-0000WF-Qk for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Oct 2022 16:54:30 +0200 Original-Received: from localhost ([::1]:56084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogok9-0006t9-S4 for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Oct 2022 10:54:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogmf1-0002EC-LZ for emacs-devel@gnu.org; Fri, 07 Oct 2022 08:41:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48674) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogmf0-00056Z-TS; Fri, 07 Oct 2022 08:41:02 -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=+IyEOCEj85n3jCZSRfcpEzGys5RTKnB4G8705zSV1Qg=; b=kKHDo/uFYZr/ gBeACgJAm2r+BWyWrBlVzg8iEgjM8QDVQfhgTp9A++/FIZ61y+wOyNPd8ljSPMzkRvYv+OcaDH73q 8e1bkFQRloeSO77Y+KuJM+vO1IBDOB/a5CGcNwaLIMi2kgkTVRNq6S12NANYM1SOtCm6L4DOqwoJf VEnFzbPCr6XwK48QLx28Q0OpJ4Axg1YUxI6GdCY5aKg4HER/NFSI/rxoFnW07topXigkQgqwEUdNN rrVZ2iMGkD/5jBZhSMzO6SVnuLEHqw9yjhiTbgMVgkFADB3YWOYW4Q0+a3qOeF+WkB6muKwH16GpJ 0rIW4qR9MzDFKGNDRpB5aQ==; Original-Received: from [87.69.77.57] (port=2052 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 1ogmer-0006oc-25; Fri, 07 Oct 2022 08:41:02 -0400 In-Reply-To: (tomas@tuxteam.de) 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:297153 Archived-At: > Date: Thu, 6 Oct 2022 13:49:44 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > On Thu, Oct 06, 2022 at 01:13:40PM +0300, Eli Zaretskii wrote: > > > Date: Thu, 6 Oct 2022 11:02:44 +0200 > > > From: > > > > > > > > The solution I would propose would be to defer JIT native-compilation > > > > > until the computer is on AC power, as determined by battery.el. > > > > > > > > We could have such a feature, but how to implement it? If we use a > > > > timer for that, the timer itself will drain the battery. > > > > > > Guessing from a previous mail by you, the correct way to achieve this > > > is to compiler results to a non-existent directory, right? > > > > No, this is a completely different use case. > > Now I'm confused. Does the non-existence of a target directory > disable compilation or just the writing of the compilation's > results? ??? What does the existence of the target directory have to do with the use case of laptop running on batteries? > > What would you like to be documented, exactly? > > that pointing HOME a non-existing directory is the way to either > inhibit JIT compilation or writing of the compilation results to > disk (depending on the answer above). That is not something we should advertise, I think, because it shouldn't be needed. We do that in the test suite, but not in order to disable native-compilation. Whether there are valid use cases where users would need to disable native-compilation is still an open question. The use case presented by Po Lu does not require disabling native-compilation, it requires _delaying_ it until some opportune moment.