From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id mB3GBhqBPWIxmAAAgWs5BA (envelope-from ) for ; Fri, 25 Mar 2022 09:45:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id oBFBAxqBPWLXogAAauVa8A (envelope-from ) for ; Fri, 25 Mar 2022 09:45:14 +0100 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 7A81216402 for ; Fri, 25 Mar 2022 09:45:13 +0100 (CET) Received: from localhost ([::1]:55164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nXfZH-0002GT-Bx for larch@yhetil.org; Fri, 25 Mar 2022 04:45:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35708) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nXfZ8-0002G2-Nb for guix-patches@gnu.org; Fri, 25 Mar 2022 04:45:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:56153) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nXfZ8-00061m-8S for guix-patches@gnu.org; Fri, 25 Mar 2022 04:45:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nXfZ8-0000Al-5u for guix-patches@gnu.org; Fri, 25 Mar 2022 04:45:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#54539] [PATCH 0/6] Start breaking up import cycles Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 25 Mar 2022 08:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54539 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos , zimoun Cc: 54539@debbugs.gnu.org Received: via spool by 54539-submit@debbugs.gnu.org id=B54539.1648197883612 (code B ref 54539); Fri, 25 Mar 2022 08:45:02 +0000 Received: (at 54539) by debbugs.gnu.org; 25 Mar 2022 08:44:43 +0000 Received: from localhost ([127.0.0.1]:50050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nXfYp-00009o-0g for submit@debbugs.gnu.org; Fri, 25 Mar 2022 04:44:43 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:62147) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nXfYn-00009b-In for 54539@debbugs.gnu.org; Fri, 25 Mar 2022 04:44:42 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4KPwd158vSz1LZX0; Fri, 25 Mar 2022 09:44:37 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4KPwd158vSz1LZX0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1648197878; bh=B6g6w/5HeGXZtycN7eBxknrzEGSTe6Yvsd6MfJg+9bQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=DCZmDE4hlH/Xb8SDHBl/KwGnTOaUgEIV+f+IoizydqoCCHZlJybnfDlX1MP/KlrVa pV4Q1gMtRUL/gwK5U8VLK/PDoELjvkqAUYEKzvhyLLvuKzVqbcbMke0TVtW7XGMZuJ 3zmooBIj2NxOk+z/L8C5P8Yvc7azhMAvfwKKNdj0= Message-ID: <84da9090d9dee87855ee4f5b2f5442ad919ea032.camel@ist.tugraz.at> From: Liliana Marie Prikler Date: Fri, 25 Mar 2022 09:44:38 +0100 In-Reply-To: <2b5a3af9bd4ea9ec79ad9f9636ed344a51ba7a81.camel@telenet.be> References: <5a87d6f772ff7424cb6fccea7c45276bef7797aa.camel@telenet.be> <5ab234b577c15dd50c36aaf427cce593404b52dc.camel@ist.tugraz.at> <2b5a3af9bd4ea9ec79ad9f9636ed344a51ba7a81.camel@telenet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" 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=1648197913; 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: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=B6g6w/5HeGXZtycN7eBxknrzEGSTe6Yvsd6MfJg+9bQ=; b=M4PhPzShIp1jem2OoeOBRRKatTv9B4sTJ6zIspAyQ3eBh2D/HkhJXNoYIn479rk/FXEXcW haHjAtChUm2M87CeylNFP0UIasg+GI7TJhcGkzT8c2SV0eaTEBYD+zMhvE/S/Qg7I5Ctip YvgLF3zrdgfQh8TaZfpY7eVBWhgfc1H6NCZNWgAGqDmpkjyoH8aPQG1gZu/iiCvUODv4Ui +nRHocjgW2vty18kTWjK/RvmrugVaV21sxGfAoZxoQPRWJ5jevJGroSD5ulwSgQoZvn6qq zrLdZrGhIHwpuGlOdP5TRT5Tv7xroEnp26c0ZFWbqVWlT2P0Z9vFQXy1rSIUvQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648197913; a=rsa-sha256; cv=none; b=flSvuIJBNhyEx2fsfPSzeQ3cZQSghaoNzpw84FD51iWX3gM9YYr8W3uX26tnIH7LFCRv1I IG66ke+c4Cz+NWCJ7FXKQZCTcZImbirrh1ZrMiL27549K1cUkKvo753sMp8nQHgYobLLDS SOQfwZesl5qf3Sk0pjT5UzyA/kAB/90MjO1A3SUFwpDsvlbU1plULhi/gjxZq/r9YHsFiE 6vwTA4sfyh4qIDWTPdJz4oBAIUGbjFkTamZ2Ixx5uaGoj0acXilIyHt06S0At9NW2GN/5Z F51prHj7yl8Rt5pfL9aMlZLYYzMfWpOc5wcCcvRHcQW7eSe962csCjiau5RCjw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=DCZmDE4h; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.71 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=DCZmDE4h; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 7A81216402 X-Spam-Score: 5.71 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2p9VH4etraJ+ Am Donnerstag, dem 24.03.2022 um 19:07 +0100 schrieb Maxime Devos: > zimoun schreef op do 24-03-2022 om 17:58 [+0100]: > > I agree that lazyness is a good thing and a good direction.  > > However, let be pragmatic with what we have now. :-)  What are the > > performance comparison between breaking many cycles as Maxime is > > proposing vs using many 'module-ref' + 'resolve-interface' instead > > of break? > > Currently this patch series does not improve anything much, according > to "guix graph --type=module hello | wc --lines".  I'm now > introducing some module-ref+resolve-interface --- it's very > convenient, but I'm not yet at a significant result. For the record, my suggestion to declare lazily loaded modules near the top is based on the fact that Maxime's current patch set uses them to break up cycles in a manner that also requires a comment in the define- module clause for the sake of clarity. As a nice side effect, it makes it so that two-liners in the inputs field become one-liners. The question is (on a per-module basis) whether we consider this cheat fine or whether we want to move things into different files (and which). I so far haven't heard a good argument for the case of audacity I raised. "It breaks cycles" is not good enough when we consider the potential existence of other cuts (e.g. "audio-apps", although perhaps a more specific "audio-editors" similar to how we have "image-viewers" might make more sense), as well as the cheat of lazy imports. simon, you raise some important performance metrics, but there is such a thing as optimizing for the wrong metric. There are other variables to consider, like time to grep, "does it make sense that X belongs to Y and Z doesn't", etc., when it comes to ease of contributing. Declaring some modules banned for a given other module has an adverse effect here, in my opinion, and thus I claim that we need easily accessible ways of using those supposedly banned modules. Btw. regarding style, I think declaring a function @PACKAGE_MODULE, i.e. a literal '@ followed by the last symbol in the module's name, would be the easiest, as one could read (@PACKAGE_MODULE arg) as a shorthand for (@ (gnu packages PACKAGE_MODULE) arg). Somewhat off- topic, what's the rationale behind not using @ syntax? Does @ have different semantics from resolve-interface + module-ref? Cheers