From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id wMXQElK4mWIkTgEAbAwnHQ (envelope-from ) for ; Fri, 03 Jun 2022 09:29:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id oDbGElK4mWLK7QAA9RJhRA (envelope-from ) for ; Fri, 03 Jun 2022 09:29:22 +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 A5E722F953 for ; Fri, 3 Jun 2022 09:29:21 +0200 (CEST) Received: from localhost ([::1]:34718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nx1kG-0002ha-84 for larch@yhetil.org; Fri, 03 Jun 2022 03:29:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx1LR-0000BX-UV for emacs-orgmode@gnu.org; Fri, 03 Jun 2022 03:03:42 -0400 Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]:35416) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nx1LQ-0004a6-1N for emacs-orgmode@gnu.org; Fri, 03 Jun 2022 03:03:41 -0400 Received: by mail-ot1-x32b.google.com with SMTP id l10-20020a9d7a8a000000b0060b151de434so4975905otn.2 for ; Fri, 03 Jun 2022 00:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=0OiWimTUhChs87XJfsRabHtICY74VlQMjR0faZE/csM=; b=HkS+w0Ymdv9NYKcezyfCS91e69mmrZh0jWw2fQQY7ySIyDOmw3w4p3L7OJLKNaTLfm lEYoql/5v9+uENy1/0W9mI3CqIBybzCxNqj4CAkCQ/R3tNe3caAb1B0gQHEIAf1UB75Y QgzQ909OyOhOpuFr6f1f8XBNZ7wS3j3EO+BjdQrNPTHDAUbjNh8awSMgxi4Sgh9KOC7a jYAVIf3XJOUBk6vlh3OhBo9DRIdE9zNOWHJWMg1b2HtBEpM/j8ApjSOKP0kPWpTfQmNM 9/Mp9cBwCceEE/CnsLj2SrJ7zK44a1cbanEe+G20sLHeKB3wbiPDiCynEd1F9j5rgPGX QyBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=0OiWimTUhChs87XJfsRabHtICY74VlQMjR0faZE/csM=; b=d+tYfmFwlu2laX6Jp7EZ7NXDTHqrM774YJwd7FbJHVF5UCdsScW4oBTwWBGfAPrbpd m+kok4+dZTZOOdd6QQKTQdCPupXVOu7i0LpSIJf6gt2bvqha20ATGU2o2ox9CgXqh0WD NRKjh+am9B96yiXh10Zp3YTsfi8mwqhxmDq+MOlkKYTpKLyfUeRP9W3F4JA5LRa9avnF QhmEbZJZXAaO3nCUCcZaUfmzlNGUSArWkct+jFoJdGvpJeHndQnyVu0ZSS6NF0YgzOZL NDr6PJPLRPyvk8LdZZPFa5/HJXl3g+NoeKO6AzNyzLI2IChcsChZ3hcEQe9WIICyK25A i1Ow== X-Gm-Message-State: AOAM532mJrbkD/6P/hJjExsFwhQdi0MqK0rxZ4ifRcKfw/8CqjP6rKu0 4VvhCwi5m5VXuoWsqSBfh56YJj91TnLizA== X-Google-Smtp-Source: ABdhPJyOfsb0zc+OAzmujC3RJ4NA0+vZZPLwshuuRBkTvt+E41wLUbgqtxtJ/qOGk6AmcDk9x40fig== X-Received: by 2002:a05:6830:304e:b0:5af:f66a:56ee with SMTP id p14-20020a056830304e00b005aff66a56eemr3608112otr.226.1654239817871; Fri, 03 Jun 2022 00:03:37 -0700 (PDT) Received: from localhost ([104.223.98.2]) by smtp.gmail.com with ESMTPSA id k10-20020a056830168a00b006068c4af381sm3182456otr.54.2022.06.03.00.03.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jun 2022 00:03:37 -0700 (PDT) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [PATCH] Re: tangle option to not write a file with same contents? In-Reply-To: References: <583051.1635393898@apollo2.minshall.org> <12cd2bb0-584e-dcff-baca-1ed27d0281ff@gmail.com> <878rrcws6q.fsf@localhost> <87r14bogp1.fsf@localhost> Date: Fri, 03 Jun 2022 15:04:14 +0800 Message-ID: <87mteucjo1.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::32b; envelope-from=yantar92@gmail.com; helo=mail-ot1-x32b.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654241362; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=0OiWimTUhChs87XJfsRabHtICY74VlQMjR0faZE/csM=; b=RbD/Hszb8KW5Aq2yW4Wmt5pQfCu5qIDtXq73+bxB2jsevpL0lDVVBommG9ODBJAGCUFjoM 7dQO1s+PhX+O7BWT/ElO2b3BHJVp8539qVCxMmDjbkcMY/eUoA2CAl8eJuWVsXa5OdkVFN UF17rdnoNuL9szktjCSH9CGgKMx+gQeUa7jCikyE6QLetL9W+HA9CHBzTo0KYgx7USA4fq /M3iKB7tdL6CTqu6zQqWig7Woef5UrcLr/zPjyN236FxW0RaQxTPunAwgDf73XWsJxsKNT utl9SqI9vGEWxvc781pTRfXPlChe1sq2dzyq/ClHfLCm72Czn2ki0kTQKKZ7KQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654241362; a=rsa-sha256; cv=none; b=H9iG4TQ2MnCnaEKnL0ozvv2YUKcIG7N8f83qHE215ZwG+75NmF1ZwYy3fqKqmCRIGDhiWa ZEGcgN6L2xQU6iF4+CfeM32tsuOHdV13+vcmJF8DOU3sUBb4wkG4ezKePuqrRnFnWWZ7f2 JY2PZv9EiqP1Jgc8dptAH0xXjnX/e1fPvOyj9Eg2ul4jxlQPPxPinTR1RE52UsfW7EZhaS n4K5bCUD2jR7sbvEnkX9ArEzzuxwA9bFR7i+4I79T1RKqp+/7OwcfpMvi8DPrU9Q5MYSlN Aobnk4fkEz3zUdFJCPo49yvsl4niRbbCNuzeidA3jKXknBtweosoZCG3een4Nw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HkS+w0Ym; dmarc=pass (policy=none) header.from=gmail.com; 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-Spam-Score: -4.52 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HkS+w0Ym; dmarc=pass (policy=none) header.from=gmail.com; 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: A5E722F953 X-Spam-Score: -4.52 X-Migadu-Scanner: scn0.migadu.com X-TUID: /7wvqYhBXqTQ Max Nikulin writes: > On 30/05/2022 10:14, Ihor Radchenko wrote: >> I applied the discussed two patches onto main via 1525a5a64 and >> f6f26d4ce. The suggested amendments were incorporated. > > So Greg's feature request is implemented and it is great. > > I am less confident with `org-babel-load-file' though. Due to poor error > handling in `org-babel-tangle' & Co., I am unsure that I can provide an > example when new code incorrectly updates file modification time despite > tangle failure, but I do not like that modification time is changed > before attempt to tangle. Generally I expected that it is performed > after tangling, perhaps with check that `org-babel-tangle-file' returned > expected file name (as some hope for success). I agree that updating the modification time after tangling will be slightly more robust in common cases. Though not necessarily strictly better. Handling errors is challenging. org-babel-tangle potentially writes to multiple files in unspecified order. Tangle error may happen in the middle of tangling when some files are written and some are not. Those tangled files could also depend on each other during loading (think of config.org tangling into init.el and config.el one requiring another). Then, an error during tangling can result in some files being tangled to newer versions and some still having old versions. Now, consider that config.org is tangled to config.el and then to init.el with the latter tangling process failing. Next time we call org-babel-load-file, the updated config.el will be loaded despite error and incorrectly require the old init.el. Another case is when init.el is tangled first and config.el tangling fails. This time, it matters whether we update the modification time of config.el (before of after tangling). In our current code (with my patch), the older version of config.el will be touched despite tangling error and next time old config.el + new init.el will be loaded. The existing code will create problems in both the described cases. If we update file modification time only after tangling succeeds without error, only the first case will be problematic. So, your proposal will indeed be more robust in a sense that it will prevent _some_ problems when tangling fails. However, I see the "robustness" as a bad thing here. org-babel-load will sometimes fail and sometimes not depending on the where in config.org the error appears. I see it as a potential nightmare for debugging. Ideally, we should solve the problem with tangle errors in some other way. I am not sure how (or rather haven't spent much time thinking). Ideas are welcome! > I have realized that the case was not exactly the same when Nicolas > asked for a patch correction: > > Nicolas Goaziou to emacs-orgmode. Re: [PATCH] Fix moving cursor in > org-set-tags-command. Fri, 08 May 2020 09:53:55 +0200. > https://list.orgmode.org/87ftca6ewc.fsf@nicolasgoaziou.fr > > "Please replace `and' with `when' if side-effects are involved." I see. `and' is indeed considered a logical statement and should not normally be abused for side-effects. But it does not imply the opposite for `when'. >> Everything is tangled to files prior to running the benchmark. This way, >> none of the tangled files should change when calling org-babel-tangle >> and no disk caches should be involved. > > I am trying to say that in your benchmark file are not read from disk, > almost certainly they are cached in memory. Besides write cache, while > reading, content may be taken from cache as well. > > Actually I am just speculating, while you have benchmark result. It is > unlikely that I will decide to spend some time arranging another test to > convince you with numbers, priority of such activity is not high enough. Let me clarify. I am looking at this benchmark from a broader perspective: - We want the patch to improve performance. - We don't want the patch to degrade performance. 1. My benchmark certainly shows that there is an improvement in some cases. It is something we want. 2. My benchmark may not be accurate depending on the system state. It is also fine. Just shows that improvement might not happen in 100% of cases. 3. Is my benchmark degrading performance? I do not see how and I do not see how your observations prove otherwise. So, unless you can see how my patch degrades performance on some systems, I do not see any reason to perform more accurate benchmarking other than for science. Best, Ihor