From unknown Thu Aug 14 20:51:47 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#56799 <56799@debbugs.gnu.org> To: bug#56799 <56799@debbugs.gnu.org> Subject: Status: (gnu services configuration) usage of *unspecified* is problematic Reply-To: bug#56799 <56799@debbugs.gnu.org> Date: Fri, 15 Aug 2025 03:51:47 +0000 retitle 56799 (gnu services configuration) usage of *unspecified* is proble= matic reassign 56799 guix submitter 56799 Maxim Cournoyer severity 56799 important thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 12:24:07 2022 Received: (at submit) by debbugs.gnu.org; 27 Jul 2022 16:24:07 +0000 Received: from localhost ([127.0.0.1]:56863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGjpP-0000rE-H8 for submit@debbugs.gnu.org; Wed, 27 Jul 2022 12:24:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:49362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGjpN-0000r6-4j for submit@debbugs.gnu.org; Wed, 27 Jul 2022 12:24:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGjpL-0004Pv-Rl for bug-guix@gnu.org; Wed, 27 Jul 2022 12:24:04 -0400 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]:38694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGjpJ-0005ow-PD for bug-guix@gnu.org; Wed, 27 Jul 2022 12:24:03 -0400 Received: by mail-qt1-x832.google.com with SMTP id y9so12994681qtv.5 for ; Wed, 27 Jul 2022 09:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version; bh=R2LtPJ9tnIq3qOLukHbaRB7ZX2/pkKbb5OCEJJuOuwU=; b=VzyQuzpsfTnRKgSdZq7QvLv5RPuR/208A/yXvDm6hqOW8M91fJlKiSnDWe35kYOsmA p6aAOnnQv38/5a26pXkL0Yzb9J/Cihl3rTyPcUmsCBcdpOlRYJl+N9rM3usItQSKk6WM urpTf0tr5dODzw7/dJuMdC65kHt6RSps8pQbCLBEq1loPiRKdcOKYsefe+uojDjNixIm KroTpYfdR3/nWBK31g98OIm1um1Szw6tnVlIpJxIeO34fkF6dkn+xhd5zvEUc7jPIdDp Pj5lEMDCdjrFdNPiKXqecXAyFa0D4dwjXkCCXXT2TtaL6UbCnY4ulDZsaCQ9+F+pSHx1 n9Nw== 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:date:message-id:mime-version; bh=R2LtPJ9tnIq3qOLukHbaRB7ZX2/pkKbb5OCEJJuOuwU=; b=sUeiQaFK0sknbSNNeG+Jtg4axQMz3G8ssUPv74pQDlEIzyfBB5swzapRxNAKbFOXXM 57B47D8VucY1tQE9kopRCa0TJolg4cvMl3uneD3g394Tbi/RPjrcJQOqKT218NQKqeDw DGO1oZTj2qUcGSSxtR9Sj1+c0foAhPTFaqzVV71oPx4GE0bHPNvzdaPJx7tZNVmJJQ9m EdjW2ukot9Gfk65+jVbOoVmiQL/Z7jfLGgGIphPA8ZAHftv0NB7VnHPtnrDwt3IXWLzp UO4n1Q0Sl1GJrVSX5BEF4VLZAJjdmNWntGFR821+HXr/F3URt89+0Zy4+vhCZGfpHnEr 8vpg== X-Gm-Message-State: AJIora+yr8nMVjWM/W82Q4Q6+WyiiH0J8XHQFrVzzrUKCUm1szrtjJUG gFiilPxe44W6DkBzRJzqmpO3k0EeTE0= X-Google-Smtp-Source: AGRyM1voCY0iCRnCkJag0zqvCQgynGlUqtq2th/0GJNmewkw5Y5e5PSeIwZpVNQTz7BNx0a6RPPQEQ== X-Received: by 2002:ac8:4e8b:0:b0:31f:2671:1682 with SMTP id 11-20020ac84e8b000000b0031f26711682mr18677390qtp.527.1658939040233; Wed, 27 Jul 2022 09:24:00 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id ck11-20020a05622a230b00b0031eeefd896esm10970172qtb.3.2022.07.27.09.23.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 09:23:59 -0700 (PDT) From: Maxim Cournoyer To: bug-guix Subject: (gnu services configuration) usage of *unspecified* is problematic Date: Wed, 27 Jul 2022 12:23:58 -0400 Message-ID: <87o7xa8qxt.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::832; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qt1-x832.google.com 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: attila@lendvai.name 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: -2.3 (--) Hello Guix, Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the define-configuration machinery in (gnu services configuration) uses *unspecified* instead of 'disabled for an unspecified field value. While this is indeed an improvement in readability, it introduces an extra complication: because this new value is not self-quoting, it cannot be used as is in G-Exps, and values using it must be carefully expanded outside the gexp context, which is error prone. This broke the jami-service-type, when partially specifying a jami-account like so: --8<---------------cut here---------------start------------->8--- (service jami-service-type (jami-configuration (accounts (list (jami-account (archive "/etc/jami/some-jami-account.gz")))))) --8<---------------cut here---------------end--------------->8--- When building the operating system containing the above fragment, the following error is throw: --8<---------------cut here---------------start------------->8--- guix system: error: #: invalid G-expression input --8<---------------cut here---------------end--------------->8--- The following change to the jami-provisioning test can also reproduce the problem: --8<---------------cut here---------------start------------->8--- modified gnu/tests/telephony.scm @@ -60,7 +60,7 @@ (define %moderators '("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" (define %dummy-jami-account (jami-account (archive %dummy-jami-account-archive) (allowed-contacts %allowed-contacts) - (moderators %moderators) +; (moderators %moderators) (rendezvous-point? #t) (peer-discovery? #f) (bootstrap-hostnames '("bootstrap.me" --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- $ make check-system TESTS=jami-provisioning Selected 1 system tests... guix build: error: #: invalid G-expression input make: *** [Makefile:6734: check-system] Error 1 --8<---------------cut here---------------end--------------->8--- I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449 to use 'unspecified (the symbol) instead of *unspecified*, which *can* be serialized without any fuss in gexps. Thoughts? Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 12:46:39 2022 Received: (at submit) by debbugs.gnu.org; 27 Jul 2022 16:46:39 +0000 Received: from localhost ([127.0.0.1]:56877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGkBD-0001X5-Ac for submit@debbugs.gnu.org; Wed, 27 Jul 2022 12:46:39 -0400 Received: from lists.gnu.org ([209.51.188.17]:41090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGkBA-0001Wv-4H for submit@debbugs.gnu.org; Wed, 27 Jul 2022 12:46:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55456) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGkB9-0002I6-2E for bug-guix@gnu.org; Wed, 27 Jul 2022 12:46:35 -0400 Received: from tobias.gr ([2a02:c205:2020:6054::1]:37570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGkB6-0000lM-1S for bug-guix@gnu.org; Wed, 27 Jul 2022 12:46:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=2018; bh=a2xwt4f192hDF Pr0bF9lXjnbPXc8ojTY1TNpLjdLTIg=; h=in-reply-to:date:subject:cc:to: from:references; d=tobias.gr; b=nWSsONkx+x1arc5nj5ZZ+7CxRTQsldbDxbOku8 ha0gbRQaaCClCoyFl3WB10Asxtz7fcbqkVB6CICsqGSCUyhcdQbP6gkosjmEX68T4WBRyl nbYByntMQXFTC/4PblNZJpN2pddLD6MPW+cMpe7ObPG2WEEbf8pLQ9zt96KcLRbB0il8/E 63IjKR+0uL4MMqi4pipBT8OgQXz+jOcjTMy9JiSLcZbsfgE6f48wnJnHjeJL4gATVt8K1a gqTkUL4gP8LD44cClpOenl4Wp/46ysEwkLUF8/BIEA5gM/2KlybFt9l7NW6D2IX3Y3gLCJ JRi2F7ROFB5Uf2i1YmcBlLbg== Received: by submission.tobias.gr (OpenSMTPD) with ESMTPSA id 61da91ba (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 27 Jul 2022 16:46:24 +0000 (UTC) References: <87o7xa8qxt.fsf@gmail.com> From: Tobias Geerinckx-Rice To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Date: Wed, 27 Jul 2022 18:43:25 +0200 In-reply-to: <87o7xa8qxt.fsf@gmail.com> BIMI-Selector: v=BIMI1; s=default; Message-ID: <87a68uqz9r@nckx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a02:c205:2020:6054::1; envelope-from=me@tobias.gr; helo=tobias.gr 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: 56799@debbugs.gnu.org, attila@lendvai.name, bug-guix@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: -2.6 (--) --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Maxim, Maxim Cournoyer =E5=86=99=E9=81=93=EF=BC=9A > I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449=20 > to use > 'unspecified (the symbol) instead of *unspecified*, which *can*=20 > be > serialized without any fuss in gexps. Bah. Could we provide our own reader? I'd much rather this be addressed in Guile (or failing that,=20 transparently by Guix) than have to deal with some magical symbol.=20 IIRC that was the argument for using *unspecified* in the first=20 place, and I think it makes sense. This looks more like an unexplored oversight than a well-reasoned=20 restriction to me. Kind regards, T G-R --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYuFr8Q0cbWVAdG9iaWFz LmdyAAoJEA2w/4hPVW15sJkA/0Y+odIvLodYbBK3Zk/833RoMq22UjxCmCF8MHMl iROZAQDKb0DEVx8YjvBWuslv06N3foavoryvyPYL3GSZ9iqkCQ== =rxNz -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 14:27:36 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 18:27:36 +0000 Received: from localhost ([127.0.0.1]:56963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGlkt-0004hl-M5 for submit@debbugs.gnu.org; Wed, 27 Jul 2022 14:27:35 -0400 Received: from mail-4317.proton.ch ([185.70.43.17]:51039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGlko-0004hR-7w for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 14:27:34 -0400 Date: Wed, 27 Jul 2022 18:27:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail; t=1658946442; x=1659205642; bh=HZN4yJHUstVEslv/slnzLhUeoIL7vPytyAeAGfXTlvo=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=UC+2LsiE22+F1P7doMGJmQjewrJ8SNZaZZMuKc6NP78uVBGemmYq11qILTeaUtS3k 1la4vHfwyB8knSMNntAFkrtIKktrcDCQrT1KvaHB7f6HbkkQZ6ID1jrL7jLvETKzen PVu5HYwV2kUia6uAdhpJ8N6s3dMoBSkU64RHFnXFp/FnW7Zh4C58HhEqGnEI7njTGb HZTv464+1as0+8cb7mzvF96R2O91u47Kc1No9i0Yx3i0239rpXDI/2iNUHbHnSQc37 khnYKPhb/wUY/5ZYLkXeZnaZhyblRDpBYrZHLeCf6t41PF7qPlS2TGdDavtvaWEQUk BQI6ItARILYzw== To: Tobias Geerinckx-Rice From: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: In-Reply-To: <87a68uqz9r@nckx> References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Maxim Cournoyer 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: , Reply-To: Attila Lendvai Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) hi, sorry for the headaches! the original discussion is here (well, i think. site is down right now): https://issues.guix.gnu.org/54674 'UNSPECIFIED would satisfy SYMBOL?, i.e. a source of headaches/confusion. i= t used to be 'DISABLED, which was even worse as it can be confused/conflate= d with a user specified value. i suggested the use of srfi-189, but it was rejected as unwelcome complexit= y. https://srfi.schemers.org/srfi-189/srfi-189.html i think it makes sense to change Guile to make *unspecified* self-evaluatin= g, but looking back, maybe the use of srfi-189 would have been better. i need to run now, and i'll be offline for a week or two. i can't look the = example in depth now, but my gut instinct says that it's a bug if *unspecif= ied* reaches any GExp machinery. more later, -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CIf you are neutral in situations of injustice, you have chosen the= side of the oppressor.=E2=80=9D =09=E2=80=94 Desmond Tutu (1931=E2=80=93) From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 14:31:42 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 18:31:42 +0000 Received: from localhost ([127.0.0.1]:56968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGlos-0004qq-By for submit@debbugs.gnu.org; Wed, 27 Jul 2022 14:31:42 -0400 Received: from mail-qv1-f52.google.com ([209.85.219.52]:46649) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGlop-0004qa-IZ for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 14:31:41 -0400 Received: by mail-qv1-f52.google.com with SMTP id x8so11711409qvo.13 for <56799@debbugs.gnu.org>; Wed, 27 Jul 2022 11:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=rwnkc0v4WYhsBIEC22Qgps13tuFzX65XrghTkBaw8aE=; b=d709W0UiqBu+i8SbjSw4YH4aNFB7V8BO9GFathewdjQF8ybDynhztg9SEvc4Jygpn9 2Bb8L7l7xrfPI/K88XwiLi0eJKuiF8TJcds6n9HJRoES/+ClaFfi2WGTV+F6mwlBp9T3 4Vr5jAFRrQ5QkJ7tu/IVLTXyKyoP6iWd4VVIcf/aFBZ+4NYokL6zTGL/VUDrv+tqMWby XKSACZt3iNlo+QOHn2S9s/8tQOn7SlRD7htoclVbj9HwAMDVkXeqhwgk0UNziVyygMTP 0xKqboAtmI60lw6Xb8D2l5bbbZR5o0BPPCm1UxE5MOoxjtlDF4rDQN5lqpSYAGUeiaqN VyEA== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=rwnkc0v4WYhsBIEC22Qgps13tuFzX65XrghTkBaw8aE=; b=ZwxXzim9hE6QrfMiXCzC4NL5mQNfVG+MmW3iw5/D4cq3ui+Qt3PeIvM5+AasUUzm3C cNqAAP2gk8IhL1wObKtyahAsL/fC6EEdaQwy2Jltk++g/df910qEUQ3AV4cFcfZ2a0LD z8K5Lx1QOIHGeJ96CSBNygPwI0HJsHZDOx/XLqt5oDFOkTUdSS3tazyorpSVjsSHc9fU 9RKmwHO3tZVeUh96hmOYRAIvmzKD2LQ0gnXEV6oX/oy8z4QrAYJA3rq+YewWbsR0tdnl vLe0hhk8tMMwNw6jIX5pBLFLviydpYvyCVjpjRYuqrG7giVAYpae5wrMV/3s3xU+SpEw JC9A== X-Gm-Message-State: AJIora+g62SXzYQS8Ek3diWq4nUp7hEUeLwIlZuP7Tskij3QVLU7HVIY IjrEXXQl/7yz+zmwv347ryo= X-Google-Smtp-Source: AGRyM1vppDqdmoetOjLwth3jbgRMCVPOFHWDT42GjdRXa9HnR4lzlod5HebQVICYs/Ij5qtSh8hkUw== X-Received: by 2002:a05:6214:29c7:b0:473:7b25:f950 with SMTP id gh7-20020a05621429c700b004737b25f950mr20706600qvb.95.1658946693904; Wed, 27 Jul 2022 11:31:33 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id bn31-20020a05620a2adf00b006b5ef0aff29sm13062135qkb.87.2022.07.27.11.31.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 11:31:33 -0700 (PDT) From: Maxim Cournoyer To: Tobias Geerinckx-Rice Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> Date: Wed, 27 Jul 2022 14:31:32 -0400 In-Reply-To: <87a68uqz9r@nckx> (Tobias Geerinckx-Rice's message of "Wed, 27 Jul 2022 18:43:25 +0200") Message-ID: <87fsim8l17.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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, Tobias Geerinckx-Rice writes: > Hi Maxim, > > Maxim Cournoyer =E5=86=99=E9=81=93=EF=BC=9A >> I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449 to >> use >> 'unspecified (the symbol) instead of *unspecified*, which *can* be >> serialized without any fuss in gexps. > > Bah. Could we provide our own reader? > > I'd much rather this be addressed in Guile (or failing that, > transparently by Guix) than have to deal with some magical > symbol. IIRC that was the argument for using *unspecified* in the > first place, and I think it makes sense. > > This looks more like an unexplored oversight than a well-reasoned > restriction to me. This was my original impression, but thinking more about it, it became apparent that *unspecified* is well, unspecified and shouldn't be relied on by people to be something well defined. For some background reading, see [0]. So it seems wrong in Scheme to actively set things to *unspecified*, and give a specific meaning to that. I think the semantic of the language is that it is to be used as the lack of a return value from a procedure or syntax, e.g.: (unspecified? (if #f 'one-arm-if)) -> #t Having 'unspecified?' even defined in Guile seems to go against that idea; perhaps because Wingo themselves seems to disagree in [0]. I'm also thinking 'unspecified being too close to *unspecified* is probably going to cause confusion down the line. Reverting to the originally used 'disabled may be the lesser evil. Other thoughts? Thanks, Maxim [0] https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified= -values From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 14:55:49 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 18:55:49 +0000 Received: from localhost ([127.0.0.1]:56990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmCC-0005Zy-J7 for submit@debbugs.gnu.org; Wed, 27 Jul 2022 14:55:48 -0400 Received: from tobias.gr ([80.241.217.52]:39474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmC9-0005Zn-Uy for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 14:55:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=2018; bh=K0gyKmP8Wupb5 Kyk9XdZqXgoOF5Gl16GFUyUX7QctPY=; h=in-reply-to:date:subject:cc:to: from:references; d=tobias.gr; b=cAgb/MQ1rvnUFnIy5Ai21acJZL6aNvcUVCQGHZ 7wlA5yLs5z/W9SXffYN9jwCJYColrx4mDM1meBagH6BbzGfBFMG2NhFuagyE9aGTUX5Dqh aw9hOVCvbH0exFqfyIfNFXqY/oTJfFl0XGUsV7wTB6XXMduISgnXKzkImZ3eEqnz0YHpAp oP5ikrgIadCxyRj14h/eq0AG4It7d+NZ0VyHhDCaDJFBJBH/kWsD38JAUVI1dlMT+cZzii yf6R6a8UVtgtNdRfuZ9n/FjnWhb9U936DwHE9lwjLKd+geFOAmI9Z1nEIPDwDYhU5cgn05 ufgn8c9CID1T/zmem5jRihNA== Received: by submission.tobias.gr (OpenSMTPD) with ESMTPSA id 2d5c7e9a (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 27 Jul 2022 18:55:40 +0000 (UTC) References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> From: Tobias Geerinckx-Rice To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Date: Wed, 27 Jul 2022 20:45:19 +0200 In-reply-to: <87fsim8l17.fsf@gmail.com> BIMI-Selector: v=BIMI1; s=default; Message-ID: <87wnbypepu@nckx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Maxim, Maxim Cournoyer =E5=86=99=E9=81=93=EF=BC=9A > For some background reading, see [0]. Thanks for the well-thought-out reply, and sharing this=20 interesting link! Now, it's just the musings of one person, but now I think I do=20 agree with (what I think is) the underlying vision: to hush up=20 *unspecified* and sneakily replace it with true nothingness. OK,=20 I can live with that. :-) > I think the semantic of the language is that it is to be used as=20 > the > lack of a return value from a procedure or syntax, e.g.: > > (unspecified? (if #f 'one-arm-if)) -> #t Well=E2=80=A6 in the above context I'd hesitate to even imply =E2=80=98sema= ntics=E2=80=99.=20 It's like undefined behaviour in C. Ascribe it meaning at your=20 peril. Otherwise, point taken. > Having 'unspecified?' even defined in Guile seems to go against=20 > that > idea; perhaps because Wingo themselves seems to disagree in [0]. Agreed. *This* was one of my reasons for supporting (field=20 *unspecified*), so it's nice to have it validated, even if it is=20 rejected. > I'm also thinking 'unspecified being too close to *unspecified*=20 > is > probably going to cause confusion down the line. Reverting to=20 > the > originally used 'disabled may be the lesser evil. Ah, here I can concentrate all my previous disagreement: hell no=20 :-) It is the worstest evil; literally anything is better than=20 (enable-foo? 'disabled) defaulting to #t. Bikeshed this all y'all want, but 'default or 'unset or 'whatever=20 are miles better. Kind regards, T G-R --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYuGKPQ0cbWVAdG9iaWFz LmdyAAoJEA2w/4hPVW15G54A/iMdVlrz9+loBRLqgm70RVbxh47GJhUBjJyuoEsl wSE2AQCUtLW3onLxfpc16g8mae9+654tiwvVLhkuZReHilSxAQ== =t/ZF -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 15:09:46 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 19:09:46 +0000 Received: from localhost ([127.0.0.1]:57037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmPi-00062g-0W for submit@debbugs.gnu.org; Wed, 27 Jul 2022 15:09:46 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:38739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmPg-00062N-2e for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 15:09:44 -0400 Received: by mail-qt1-f169.google.com with SMTP id y9so13327739qtv.5 for <56799@debbugs.gnu.org>; Wed, 27 Jul 2022 12:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Xbgl2uhsDExbXwWUcDP2887ZVdGTgKgCjR/37UpZkIk=; b=NV16nV8nEONl+VYpPdJFpsSLqEyh3fw4tmIxhIRyxcJqN9TUW+TkEtdKoGcqL1WwzJ h2teFzikCmKE+o6sWZ9S30BFc9IFo3+ASAliblggHCLmXBsxmipUxG001R38GiL0USge u129SfYAOAICD8k2wI3xuFfQIb38RdX59WSNpa+pWb4nv4Lx0k2JlkpmtLq9e+ZoLfpA 77W1xsCAHF4G8c7mKQLt8OPNqgrRpDkCy95nyHWS5oyiaue7KqsSsF32JvHv3p8GeENY Nbb1HIJMHMJqL89rxExEr+F2lsatXAViu7/KrnXlQ72SMuJH9apwhOBIQMoKkIjjq5BB 7TdA== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Xbgl2uhsDExbXwWUcDP2887ZVdGTgKgCjR/37UpZkIk=; b=XPv6WfwihRPxzlP39EqNTcdrgrn6Gwmj7zAeQ5x4GpbhCnZvmsM9uw3vrqEmf7alGw qBhUHvHPjOCRsidxPrTwwt+o16TnBh8P7b7Fg3FrYpiShwj4ZOLe+7/auv3jOgd0YGLi q7CggWh1J2p55Qk9putKle17TNJUqGpUkX/54qccGZAxoBJCkP0vQG0Ycbk/Zr2ZlcRf T+NOICMG+T7Cj80yBHPJFkopxWo5Z8B37j6PxiWQxA2IU2z3W4ticXSjDrQw74Sek6Ml NFOtiyg3zDNp/0zF6gNtFUsoYHnOrsFh32hnbaOaBqiShYYW3GTAMrx4EdhgJpWxbitS i10w== X-Gm-Message-State: AJIora+T8Vf0QMhp3Cn28B+lx/3UGm8UHe+wD7D1trG1IIIZd0C41ys0 yQI7hphqAm1HjIrd1Sl7koQ= X-Google-Smtp-Source: AGRyM1ugen8aCMfY7UNVmfzIHGGbNRSUDP9ZPObzyK2UciHbBF8B7zgJDjhkvFaiE9OvEOOysIctxQ== X-Received: by 2002:a05:622a:2cc:b0:31f:523:c318 with SMTP id a12-20020a05622a02cc00b0031f0523c318mr19644552qtx.286.1658948978181; Wed, 27 Jul 2022 12:09:38 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id bj9-20020a05620a190900b006a6a7b4e7besm13884037qkb.109.2022.07.27.12.09.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 12:09:37 -0700 (PDT) From: Maxim Cournoyer To: Tobias Geerinckx-Rice Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <87wnbypepu@nckx> Date: Wed, 27 Jul 2022 15:09:36 -0400 In-Reply-To: <87wnbypepu@nckx> (Tobias Geerinckx-Rice's message of "Wed, 27 Jul 2022 20:45:19 +0200") Message-ID: <87bkta8j9r.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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, Tobias Geerinckx-Rice writes: > Hi Maxim, > > Maxim Cournoyer =E5=86=99=E9=81=93=EF=BC=9A >> For some background reading, see [0]. > > Thanks for the well-thought-out reply, and sharing this interesting > link! > > Now, it's just the musings of one person, but now I think I do agree > with (what I think is) the underlying vision: to hush up *unspecified* > and sneakily replace it with true nothingness. OK, I can live with > that. :-) > >> I think the semantic of the language is that it is to be used as the >> lack of a return value from a procedure or syntax, e.g.: >> >> (unspecified? (if #f 'one-arm-if)) -> #t > > Well=E2=80=A6 in the above context I'd hesitate to even imply > =E2=80=98semantics=E2=80=99. It's like undefined behaviour in C. Ascribe= it meaning > at your peril. Otherwise, point taken. > >> Having 'unspecified?' even defined in Guile seems to go against that >> idea; perhaps because Wingo themselves seems to disagree in [0]. > > Agreed. *This* was one of my reasons for supporting (field > *unspecified*), so it's nice to have it validated, even if it is > rejected. Good to know I wasn't the only one nudged into thinking the 'unspecified?' procedure somehow justified using *unspecified* directly. >> I'm also thinking 'unspecified being too close to *unspecified* is >> probably going to cause confusion down the line. Reverting to the >> originally used 'disabled may be the lesser evil. > Ah, here I can concentrate all my previous disagreement: hell no :-) > > It is the worstest evil; literally anything is better than > (enable-foo? 'disabled) defaulting to #t. > > Bikeshed this all y'all want, but 'default or 'unset or 'whatever are > miles better. Thanks for sharing your idea! The neat thing here, is that even if we disagree about 'unspecified in the patch I'm about to send, we can discuss it to length then fix the end result in a second using sed ;-). Thanks for your input! Maxim From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 15:45:43 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 19:45:43 +0000 Received: from localhost ([127.0.0.1]:57067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmyU-0007El-7j for submit@debbugs.gnu.org; Wed, 27 Jul 2022 15:45:43 -0400 Received: from mail-qt1-f175.google.com ([209.85.160.175]:37396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmyR-0007ER-2I for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 15:45:41 -0400 Received: by mail-qt1-f175.google.com with SMTP id l14so13379569qtv.4 for <56799@debbugs.gnu.org>; Wed, 27 Jul 2022 12:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nS9osd5yctJu5F1+Y8Dtexq7t0DIPMGe3FuuWXY5coQ=; b=G0/S61pcVJDVzs+wwIbcvoSb0MFjA9Z+VYvesqpYOq9EzC19UDnLBX+wFhC0MYGF5/ ksz2ZTqK2RqS7Itb00HqBKr1sBZh0P1LcdRIchR1f8y6SJClPETuYXTimLMzK3uhR99n 6aWJABwpVTcsUPo4f9rvpVIl+ZRBNJvXQACPQ6aMhUKMnIbjc1pIXGCTkTqb/YUFEacq Ze6g1MkixW4xDei/1VugU5K/FnPEHVIHw+1G9SzyGEjKQTAZ1TByQpFP9o3ivouGcQdS wbL1GdDYyOSJRXPOLIHMR5BNOZEw31hVEI1Bt0oEWsRFGWpyqAOdZBr9QeuOxHF9JM4i GThQ== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nS9osd5yctJu5F1+Y8Dtexq7t0DIPMGe3FuuWXY5coQ=; b=yrR26BgIeVUnl7n37ubAsTaRf2Jfix/NN6EccxW4BV5nzJ68KEdoRuhXH0qrJGxEcO cbIaGpN30TVaTPXfTGOc9A/pvAm0S79eyFnOYop4yBMVFkEMyv5Wn+Bz6ROt9sc7Zr+e hjp1ajvyZ0SlGhsCmU+aUBsZ/f/RkbAx+APulVkhZJzZj7vp62plsX+VheFYCnYLWXog nAxtpH7UXA6yNXU9SZ46jrkHqWAeZIi41RPdrlcjEmlwBFYJGpye9mF+iQsUtF71wXl+ MZPgoN2osyefTnywgdoGqufnq0XAtVqSH/4TsfV2yUYj1OmgSPQjeEPQJE/eLy9m2nj/ GmAg== X-Gm-Message-State: AJIora9jD5K9u65E1g+LfNwOVgqerwoVSBowKF9RnFGJV3rmBm+86g5F V6Bsuo4F6qCo1JAw+AAITLpBVLlegqQ= X-Google-Smtp-Source: AGRyM1vOXeYAsA4pWGOCCsoj/cfgi0phjvl10HI31sBfJC69WZiOMp1Q4LZmb3kAQfuzqA/16vTPeg== X-Received: by 2002:a05:622a:2cc:b0:31f:523:c318 with SMTP id a12-20020a05622a02cc00b0031f0523c318mr19769573qtx.286.1658951132412; Wed, 27 Jul 2022 12:45:32 -0700 (PDT) Received: from localhost.localdomain (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id i20-20020ac85c14000000b0031f16e7f899sm11449214qti.45.2022.07.27.12.45.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 12:45:31 -0700 (PDT) From: Maxim Cournoyer To: 56799@debbugs.gnu.org Subject: [PATCH] services: configuration: Step back from *unspecified*. Date: Wed, 27 Jul 2022 15:45:10 -0400 Message-Id: <20220727194510.13725-1-maxim.cournoyer@gmail.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <87bkta8j9r.fsf@gmail.com> References: <87bkta8j9r.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Fixes . This partially reverts 8cb1a49a3998c39f315a4199b7d4a121a6d66449. Rationale: *unspecified* cannot be serialized thus used as a G-Expression input, which is problematic/inconvenient when using deeply nested records. As an example, jami-service-type was broken when us [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: yoctocell.xyz (xyz)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (maxim.cournoyer[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.160.175 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.160.175 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 56799 Cc: Maxim Cournoyer 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 (+) Fixes . This partially reverts 8cb1a49a3998c39f315a4199b7d4a121a6d66449. Rationale: *unspecified* cannot be serialized thus used as a G-Expression input, which is problematic/inconvenient when using deeply nested records. As an example, jami-service-type was broken when using partially defined records. * gnu/services/configuration.scm (define-maybe-helper): Check against the 'unspecified symbol. (normalize-field-type+def): Adjust value to 'unspecified. (define-configuration-helper): Use 'unspecified as the default value thunk. * gnu/services/file-sharing.scm (serialize-maybe-string): Check against the 'unspecified symbol. (serialize-maybe-file-object): Likewise. * gnu/services/messaging.scm (define-all-configurations): Use 'unspecified as value. (raw-content?): Check against 'unspecified symbol. (prosody-configuration)[http-max-content-size]: Default to 'unspecified. [http-external-url]: Likewise. [mod-muc]: Likewise. [raw-content]: Likewise. * gnu/services/networking.scm (opendht-configuration): Adjust documentation. * gnu/services/telephony.scm (jami-shepherd-services): Replace *undefined* with the 'unspecified symbol. * tests/services/configuration.scm ("maybe type, no default"): Check against the 'unspecified symbol. * doc/guix.texi: Regenerate the opendht-configuration, openvpn-client-configuration and openvpn-server-configuration documentation. --- doc/guix.texi | 367 +++++++------------------------ gnu/services/configuration.scm | 11 +- gnu/services/file-sharing.scm | 4 +- gnu/services/messaging.scm | 12 +- gnu/services/networking.scm | 6 +- gnu/services/telephony.scm | 6 +- tests/services/configuration.scm | 6 +- 7 files changed, 102 insertions(+), 310 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index 12ecc1b952..a2ccf913da 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -19767,75 +19767,46 @@ The value of this service is a @code{opendht-configuration} object, as described below. @end defvr -@deftp {Data Type} opendht-configuration -This is the data type for the OpenDHT service configuration. - @c The fields documentation has been auto-generated using the @c configuration->documentation procedure from @c (gnu services configuration). +@deftp {Data Type} opendht-configuration Available @code{opendht-configuration} fields are: -@deftypevr {@code{opendht-configuration} parameter} package opendht +@table @asis +@item @code{opendht} (default: @code{opendht}) (type: file-like) The @code{opendht} package to use. -@end deftypevr - -@deftypevr {@code{opendht-configuration} parameter} boolean peer-discovery? +@item @code{peer-discovery?} (default: @code{#f}) (type: boolean) Whether to enable the multicast local peer discovery mechanism. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{opendht-configuration} parameter} boolean enable-logging? +@item @code{enable-logging?} (default: @code{#f}) (type: boolean) Whether to enable logging messages to syslog. It is disabled by default as it is rather verbose. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{opendht-configuration} parameter} boolean debug? +@item @code{debug?} (default: @code{#f}) (type: boolean) Whether to enable debug-level logging messages. This has no effect if logging is disabled. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{opendht-configuration} parameter} maybe-string bootstrap-host +@item @code{bootstrap-host} (default: @code{"bootstrap.jami.net:4222"}) (type: maybe-string) The node host name that is used to make the first connection to the network. A specific port value can be provided by appending the @code{:PORT} suffix. By default, it uses the Jami bootstrap nodes, but any host can be specified here. It's also possible to disable -bootsrapping by explicitly setting this to the @code{*unspecified*} -value. +bootstrapping by explicitly setting this field to the +@code{'unspecified} value. -Defaults to @samp{"bootstrap.jami.net:4222"}. - -@end deftypevr - -@deftypevr {@code{opendht-configuration} parameter} maybe-number port -The UDP port to bind to. When explicitly set to @code{*unspecified*}, -an available port is automatically selected. - -Defaults to @samp{4222}. - -@end deftypevr +@item @code{port} (default: @code{4222}) (type: maybe-number) +The UDP port to bind to. When left unspecified, an available port is +automatically selected. -@deftypevr {@code{opendht-configuration} parameter} maybe-number proxy-server-port +@item @code{proxy-server-port} (type: maybe-number) Spawn a proxy server listening on the specified port. -Defaults to @samp{disabled}. - -@end deftypevr - -@deftypevr {@code{opendht-configuration} parameter} maybe-number proxy-server-port-tls +@item @code{proxy-server-port-tls} (type: maybe-number) Spawn a proxy server listening to TLS connections on the specified port. -Defaults to @samp{disabled}. - -@end deftypevr +@end table @end deftp @cindex Tor @@ -30525,362 +30496,184 @@ Both can be run simultaneously. @c %automatically generated documentation +@deftp {Data Type} openvpn-client-configuration Available @code{openvpn-client-configuration} fields are: -@deftypevr {@code{openvpn-client-configuration} parameter} package openvpn +@table @asis +@item @code{openvpn} (default: @code{openvpn}) (type: file-like) The OpenVPN package. -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} string pid-file +@item @code{pid-file} (default: @code{"/var/run/openvpn/openvpn.pid"}) (type: string) The OpenVPN pid file. -Defaults to @samp{"/var/run/openvpn/openvpn.pid"}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} proto proto +@item @code{proto} (default: @code{udp}) (type: proto) The protocol (UDP or TCP) used to open a channel between clients and servers. -Defaults to @samp{udp}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} dev dev +@item @code{dev} (default: @code{tun}) (type: dev) The device type used to represent the VPN connection. -Defaults to @samp{tun}. - -@end deftypevr - -If you do not have some of these files (eg.@: you use a username and -password), you can disable any of the following three fields by setting -it to @code{*unspecified*}. - -@deftypevr {@code{openvpn-client-configuration} parameter} maybe-string ca +@item @code{ca} (default: @code{"/etc/openvpn/ca.crt"}) (type: maybe-string) The certificate authority to check connections against. -Defaults to @samp{"/etc/openvpn/ca.crt"}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} maybe-string cert +@item @code{cert} (default: @code{"/etc/openvpn/client.crt"}) (type: maybe-string) The certificate of the machine the daemon is running on. It should be signed by the authority given in @code{ca}. -Defaults to @samp{"/etc/openvpn/client.crt"}. +@item @code{key} (default: @code{"/etc/openvpn/client.key"}) (type: maybe-string) +The key of the machine the daemon is running on. It must be the key +whose certificate is @code{cert}. -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} maybe-string key -The key of the machine the daemon is running on. It must be the key whose -certificate is @code{cert}. - -Defaults to @samp{"/etc/openvpn/client.key"}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} boolean comp-lzo? +@item @code{comp-lzo?} (default: @code{#t}) (type: boolean) Whether to use the lzo compression algorithm. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} boolean persist-key? +@item @code{persist-key?} (default: @code{#t}) (type: boolean) Don't re-read key files across SIGUSR1 or --ping-restart. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} boolean persist-tun? +@item @code{persist-tun?} (default: @code{#t}) (type: boolean) Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} boolean fast-io? +@item @code{fast-io?} (default: @code{#f}) (type: boolean) (Experimental) Optimize TUN/TAP/UDP I/O writes by avoiding a call to poll/epoll/select prior to the write operation. -Defaults to @samp{#f}. -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} number verbosity +@item @code{verbosity} (default: @code{3}) (type: number) Verbosity level. -Defaults to @samp{3}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} tls-auth-client tls-auth +@item @code{tls-auth} (default: @code{#f}) (type: tls-auth-client) Add an additional layer of HMAC authentication on top of the TLS control channel to protect against DoS attacks. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} maybe-string auth-user-pass +@item @code{auth-user-pass} (type: maybe-string) Authenticate with server using username/password. The option is a file -containing username/password on 2 lines. Do not use a file-like object as it -would be added to the store and readable by any user. +containing username/password on 2 lines. Do not use a file-like object +as it would be added to the store and readable by any user. -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} key-usage verify-key-usage? +@item @code{verify-key-usage?} (default: @code{#t}) (type: key-usage) Whether to check the server certificate has server usage extension. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} bind bind? +@item @code{bind?} (default: @code{#f}) (type: bind) Bind to a specific local port number. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} resolv-retry resolv-retry? +@item @code{resolv-retry?} (default: @code{#t}) (type: resolv-retry) Retry resolving server address. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-client-configuration} parameter} openvpn-remote-list remote +@item @code{remote} (default: @code{()}) (type: openvpn-remote-list) A list of remote servers to connect to. -Defaults to @samp{()}. - +@deftp {Data Type} openvpn-remote-configuration Available @code{openvpn-remote-configuration} fields are: -@deftypevr {@code{openvpn-remote-configuration} parameter} string name +@table @asis +@item @code{name} (default: @code{"my-server"}) (type: string) Server name. -Defaults to @samp{"my-server"}. +@item @code{port} (default: @code{1194}) (type: number) +Port number the server listens to. -@end deftypevr +@end table -@deftypevr {@code{openvpn-remote-configuration} parameter} number port -Port number the server listens to. +@end deftp -Defaults to @samp{1194}. +@end table -@end deftypevr +@end deftp -@end deftypevr @c %end of automatic openvpn-client documentation @c %automatically generated documentation +@deftp {Data Type} openvpn-server-configuration Available @code{openvpn-server-configuration} fields are: -@deftypevr {@code{openvpn-server-configuration} parameter} package openvpn +@table @asis +@item @code{openvpn} (default: @code{openvpn}) (type: file-like) The OpenVPN package. -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} string pid-file +@item @code{pid-file} (default: @code{"/var/run/openvpn/openvpn.pid"}) (type: string) The OpenVPN pid file. -Defaults to @samp{"/var/run/openvpn/openvpn.pid"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} proto proto +@item @code{proto} (default: @code{udp}) (type: proto) The protocol (UDP or TCP) used to open a channel between clients and servers. -Defaults to @samp{udp}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} dev dev +@item @code{dev} (default: @code{tun}) (type: dev) The device type used to represent the VPN connection. -Defaults to @samp{tun}. - -@end deftypevr - -If you do not have some of these files (eg.@: you use a username and -password), you can disable any of the following three fields by setting -it to @code{*unspecified*}. - -@deftypevr {@code{openvpn-server-configuration} parameter} maybe-string ca +@item @code{ca} (default: @code{"/etc/openvpn/ca.crt"}) (type: maybe-string) The certificate authority to check connections against. -Defaults to @samp{"/etc/openvpn/ca.crt"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} maybe-string cert +@item @code{cert} (default: @code{"/etc/openvpn/client.crt"}) (type: maybe-string) The certificate of the machine the daemon is running on. It should be signed by the authority given in @code{ca}. -Defaults to @samp{"/etc/openvpn/client.crt"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} maybe-string key -The key of the machine the daemon is running on. It must be the key whose -certificate is @code{cert}. - -Defaults to @samp{"/etc/openvpn/client.key"}. - -@end deftypevr +@item @code{key} (default: @code{"/etc/openvpn/client.key"}) (type: maybe-string) +The key of the machine the daemon is running on. It must be the key +whose certificate is @code{cert}. -@deftypevr {@code{openvpn-server-configuration} parameter} boolean comp-lzo? +@item @code{comp-lzo?} (default: @code{#t}) (type: boolean) Whether to use the lzo compression algorithm. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} boolean persist-key? +@item @code{persist-key?} (default: @code{#t}) (type: boolean) Don't re-read key files across SIGUSR1 or --ping-restart. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} boolean persist-tun? +@item @code{persist-tun?} (default: @code{#t}) (type: boolean) Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. -Defaults to @samp{#t}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} boolean fast-io? +@item @code{fast-io?} (default: @code{#f}) (type: boolean) (Experimental) Optimize TUN/TAP/UDP I/O writes by avoiding a call to poll/epoll/select prior to the write operation. -Defaults to @samp{#f}. -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} number verbosity +@item @code{verbosity} (default: @code{3}) (type: number) Verbosity level. -Defaults to @samp{3}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} tls-auth-server tls-auth +@item @code{tls-auth} (default: @code{#f}) (type: tls-auth-server) Add an additional layer of HMAC authentication on top of the TLS control channel to protect against DoS attacks. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} number port +@item @code{port} (default: @code{1194}) (type: number) Specifies the port number on which the server listens. -Defaults to @samp{1194}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} ip-mask server +@item @code{server} (default: @code{"10.8.0.0 255.255.255.0"}) (type: ip-mask) An ip and mask specifying the subnet inside the virtual network. -Defaults to @samp{"10.8.0.0 255.255.255.0"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} cidr6 server-ipv6 +@item @code{server-ipv6} (default: @code{#f}) (type: cidr6) A CIDR notation specifying the IPv6 subnet inside the virtual network. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} string dh +@item @code{dh} (default: @code{"/etc/openvpn/dh2048.pem"}) (type: string) The Diffie-Hellman parameters file. -Defaults to @samp{"/etc/openvpn/dh2048.pem"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} string ifconfig-pool-persist +@item @code{ifconfig-pool-persist} (default: @code{"/etc/openvpn/ipp.txt"}) (type: string) The file that records client IPs. -Defaults to @samp{"/etc/openvpn/ipp.txt"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} gateway redirect-gateway? +@item @code{redirect-gateway?} (default: @code{#f}) (type: gateway) When true, the server will act as a gateway for its clients. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} boolean client-to-client? +@item @code{client-to-client?} (default: @code{#f}) (type: boolean) When true, clients are allowed to talk to each other inside the VPN. -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} keepalive keepalive +@item @code{keepalive} (default: @code{(10 120)}) (type: keepalive) Causes ping-like messages to be sent back and forth over the link so that each side knows when the other side has gone down. @code{keepalive} requires a pair. The first element is the period of the ping sending, and the second element is the timeout before considering the other side down. -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} number max-clients +@item @code{max-clients} (default: @code{100}) (type: number) The maximum number of clients. -Defaults to @samp{100}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} string status +@item @code{status} (default: @code{"/var/run/openvpn/status"}) (type: string) The status file. This file shows a small report on current connection. It is truncated and rewritten every minute. -Defaults to @samp{"/var/run/openvpn/status"}. - -@end deftypevr - -@deftypevr {@code{openvpn-server-configuration} parameter} openvpn-ccd-list client-config-dir +@item @code{client-config-dir} (default: @code{()}) (type: openvpn-ccd-list) The list of configuration for some clients. -Defaults to @samp{()}. - -Available @code{openvpn-ccd-configuration} fields are: - -@deftypevr {@code{openvpn-ccd-configuration} parameter} string name -Client name. - -Defaults to @samp{"client"}. - -@end deftypevr - -@deftypevr {@code{openvpn-ccd-configuration} parameter} ip-mask iroute -Client own network - -Defaults to @samp{#f}. - -@end deftypevr - -@deftypevr {@code{openvpn-ccd-configuration} parameter} ip-mask ifconfig-push -Client VPN IP. - -Defaults to @samp{#f}. - -@end deftypevr +@end table -@end deftypevr +@end deftp @c %end of automatic openvpn-server documentation @@ -31512,7 +31305,7 @@ Each parameter definition is preceded by its type; for example, @samp{boolean foo} indicates that the @code{foo} parameter should be specified as a boolean. Types starting with @code{maybe-} denote parameters that won't show up in TLP config file when their value is -left unset, or is explicitly set to the @code{*unspecified*} value. +left unset, or is explicitly set to the @code{'unspecified} value. @c The following documentation was initially generated by @c (generate-tlp-documentation) in (gnu services pm). Manually maintained @@ -39129,7 +38922,7 @@ macro which is a shorthand of this. Sometimes a field should not be serialized if the user doesn’t specify a value. To achieve this, you can use the @code{define-maybe} macro to define a ``maybe type''; if the value of a maybe type is left unset, or -is set to the @code{*unspecified*} value, then it will not be +is set to the @code{'unspecified} value, then it will not be serialized. When defining a ``maybe type'', the corresponding serializer for the diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index e3c101d042..3758b4e09a 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -3,7 +3,7 @@ ;;; Copyright © 2017 Mathieu Othacehe ;;; Copyright © 2017, 2018 Clément Lassieur ;;; Copyright © 2021 Xinglu Chen -;;; Copyright © 2021 Maxim Cournoyer +;;; Copyright © 2021, 2022 Maxim Cournoyer ;;; Copyright © 2021 Andrew Tropin ;;; Copyright © 2022 Maxime Devos ;;; @@ -142,8 +142,7 @@ (define (define-maybe-helper serialize? prefix syn) (id #'stem #'serialize-maybe- #'stem)))) #`(begin (define (maybe-stem? val) - (or (unspecified? val) - (stem? val))) + (or (eq? val 'unspecified) (stem? val))) #,@(if serialize? (list #'(define (serialize-maybe-stem field-name val) (if (stem? val) @@ -171,10 +170,10 @@ (define (normalize-field-type+def s) (values #'(field-type def))) ((field-type) (identifier? #'field-type) - (values #'(field-type *unspecified*))) + (values #'(field-type 'unspecified))) (field-type (identifier? #'field-type) - (values #'(field-type *unspecified*))))) + (values #'(field-type 'unspecified))))) (define (define-configuration-helper serialize? serializer-prefix syn) (syntax-case syn () @@ -262,7 +261,7 @@ (define #,(id #'stem #'stem #'-fields) (lambda () (display '#,(id #'stem #'% #'stem)) (if (eq? (syntax->datum field-default) - '*unspecified*) + 'unspecified) (configuration-missing-default-value '#,(id #'stem #'% #'stem) 'field) field-default))) diff --git a/gnu/services/file-sharing.scm b/gnu/services/file-sharing.scm index e32d1f145d..8110bb0cce 100644 --- a/gnu/services/file-sharing.scm +++ b/gnu/services/file-sharing.scm @@ -115,7 +115,7 @@ (define-maybe string) (set! serialize-maybe-string (lambda (field-name val) (serialize-string field-name - (if (unspecified? val) + (if (eq? val 'unspecified) "" val)))) @@ -180,7 +180,7 @@ (define (serialize-file-object field-name val) (define-maybe file-object) (set! serialize-maybe-file-object (lambda (field-name val) - (if (unspecified? val) + (if (eq? val 'unspecified) (serialize-string field-name "") (serialize-file-object field-name val)))) diff --git a/gnu/services/messaging.scm b/gnu/services/messaging.scm index 651f90adb2..abe814e7f5 100644 --- a/gnu/services/messaging.scm +++ b/gnu/services/messaging.scm @@ -90,7 +90,7 @@ (define (make-pred arg) ((new-def ...) (map (lambda (def target) (if (eq? 'common (syntax->datum target)) - #'*unspecified* def)) + #''unspecified def)) #'(def ...) #'(target ...))) ((new-doc ...) (map (lambda (doc target) @@ -200,7 +200,7 @@ (define (serialize-file-object-list field-name val) (define-maybe file-object-list) (define (raw-content? val) - (not (unspecified? val))) + (not (eq? val 'unspecified))) (define (serialize-raw-content field-name val) val) (define-maybe raw-content) @@ -474,12 +474,12 @@ (define-all-configurations prosody-configuration global) (http-max-content-size - (maybe-non-negative-integer *unspecified*) + (maybe-non-negative-integer 'unspecified) "Maximum allowed size of the HTTP body (in bytes)." common) (http-external-url - (maybe-string *unspecified*) + (maybe-string 'unspecified) "Some modules expose their own URL in various ways. This URL is built from the protocol, host and port used. If Prosody sits behind a proxy, the public URL will be @code{http-external-url} instead. See @@ -556,7 +556,7 @@ (define-all-configurations prosody-configuration int-component) (mod-muc - (maybe-mod-muc-configuration *unspecified*) + (maybe-mod-muc-configuration 'unspecified) "Multi-user chat (MUC) is Prosody's module for allowing you to create hosted chatrooms/conferences for XMPP users. @@ -573,7 +573,7 @@ (define-all-configurations prosody-configuration ext-component) (raw-content - (maybe-raw-content *unspecified*) + (maybe-raw-content 'unspecified) "Raw content that will be added to the configuration file." common))) diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm index b555c46040..a5f0924984 100644 --- a/gnu/services/networking.scm +++ b/gnu/services/networking.scm @@ -772,11 +772,11 @@ (define-configuration/no-serialization opendht-configuration network. A specific port value can be provided by appending the @code{:PORT} suffix. By default, it uses the Jami bootstrap nodes, but any host can be specified here. It's also possible to disable bootstrapping by explicitly -setting this field to the @code{*unspecified*} value.") +setting this field to the @code{'unspecified} value.") (port (maybe-number 4222) - "The UDP port to bind to. When set to @code{*unspecified*}, an available -port is automatically selected.") + "The UDP port to bind to. When left unspecified, an available port is +automatically selected.") (proxy-server-port maybe-number "Spawn a proxy server listening on the specified port.") diff --git a/gnu/services/telephony.scm b/gnu/services/telephony.scm index e8bfbc88c5..f099b60a0e 100644 --- a/gnu/services/telephony.scm +++ b/gnu/services/telephony.scm @@ -307,7 +307,7 @@ (define (jami-shepherd-services config) (dbus (jami-configuration-dbus config)) (dbus-daemon (file-append dbus "/bin/dbus-daemon")) (accounts (jami-configuration-accounts config)) - (declarative-mode? (not (unspecified? accounts)))) + (declarative-mode? (not (eq? 'unspecified accounts)))) (with-extensions (list guile-packrat ;used by guile-ac-d-bus guile-ac-d-bus @@ -649,7 +649,7 @@ (define (archive-name->username archive) account-details) (let ((username (archive-name->username archive))) - (when (not (unspecified? allowed-contacts)) + (when (not (eq? 'unspecified allowed-contacts)) ;; Reject calls from unknown contacts. (set-account-details '(("DHT.PublicInCalls" . "false")) username) @@ -659,7 +659,7 @@ (define (archive-name->username archive) ;; Add allowed ones. (for-each (cut add-contact <> username) allowed-contacts)) - (when (not (unspecified? moderators)) + (when (not (eq? 'unspecified moderators)) ;; Disable the 'AllModerators' property. (set-all-moderators #f username) ;; Remove all moderators. diff --git a/tests/services/configuration.scm b/tests/services/configuration.scm index 6268525317..9fea65ba58 100644 --- a/tests/services/configuration.scm +++ b/tests/services/configuration.scm @@ -151,9 +151,9 @@ (define-configuration config-with-maybe-string/no-serialization (not (defined? 'serialize-maybe-string))) (test-assert "maybe type, no default" - (unspecified? - (config-with-maybe-string/no-serialization-name - (config-with-maybe-string/no-serialization)))) + (eq? 'unspecified + (config-with-maybe-string/no-serialization-name + (config-with-maybe-string/no-serialization)))) (test-assert "maybe type, with default" (equal? -- 2.36.1 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 15:47:07 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 19:47:07 +0000 Received: from localhost ([127.0.0.1]:57076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmzr-0007Hs-6Z for submit@debbugs.gnu.org; Wed, 27 Jul 2022 15:47:07 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:42722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGmzn-0007HF-J3 for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 15:47:05 -0400 Received: by mail-qt1-f169.google.com with SMTP id w29so13380930qtv.9 for <56799@debbugs.gnu.org>; Wed, 27 Jul 2022 12:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=elhPp0AGgtpguuBqwNWXCK99uhZoA881JihDbMvRC2c=; b=Nzl53AUtdbWPwDRvw0piD8T3Bn8GNaCiRI5N6IoWuGK8JpzfOfOVPNv1hsO42XyaE3 GqPHwCC0LEqVMXK0D9lV+RJEGWvTCNuOnpfB+KfFJET/ex4H+qZxEYsmlxRqz6BKHDBr f+tAleW+Ivn6stekOByWbuY5o72GYLshd2V5qBTjWBdt0CBGRyr3Bupb3ovtic7iJbI6 d6AKuNRYUQUfSEMFDu4HYh88wp36ndIgUzjxH4uPNqPzNA5Dl9EKD+sQqiMb7FvUi8SH 8m7kuAtB6M2Nx4H1sgTP0brnKtNoVljURTajiDbcr9M8iBGhlIKGZDvfCjQPQ4QhNiXV 5ToA== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=elhPp0AGgtpguuBqwNWXCK99uhZoA881JihDbMvRC2c=; b=j4d+8SZ9ACVrH7Ts8+yj0qYNqdCK2ZXCEK6pk6mJ11ihVScq01rQvXQRlQ8Iyuvunm Khi7/gjE5xAMBl3kZy8ubaYsf8RPQZLRkEWc+YX4+fkk1HfbyWrI90qF5uxB3PhaWK6s jgyzFbG9FywGqoWT99EboGbCx3/zbwcJSfg1N3aHuZcvsGzeWuY1xttzje+2+RSCo3Wb 1ANn4+tVUOxPIHDLcBLIxNCWtR88kltWamvrHEoAuXpKalp2KGyWX/JEQeb2VmsVVjUZ UdIjHCuaK8onMIk1oUWzDZ0BuAKabpuhN3xS3wvxYLwqskTBUnvB2UxvoJlD4FuWCXCX 9PIw== X-Gm-Message-State: AJIora9tHs6QGAUop84fNopwqclPfzzFYEAT1lUFOMZTo4NVI+sSc9GB x2YuQ52mZ3sKQFzChxnGQVIpgSS1sEc= X-Google-Smtp-Source: AGRyM1sD2KoI+PJNwSD/FhBkBajdMYpcUO3in6CP/KgefFj7crfurUr1+w5lU2FsH6zOtZoYxLG7qw== X-Received: by 2002:ac8:5c0b:0:b0:31f:4d00:bc5 with SMTP id i11-20020ac85c0b000000b0031f4d000bc5mr2599596qti.237.1658951218195; Wed, 27 Jul 2022 12:46:58 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id k20-20020a05622a03d400b0031eb5648b86sm11888445qtx.41.2022.07.27.12.46.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 12:46:57 -0700 (PDT) From: Maxim Cournoyer To: Tobias Geerinckx-Rice Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <87wnbypepu@nckx> <87bkta8j9r.fsf@gmail.com> Date: Wed, 27 Jul 2022 15:46:56 -0400 In-Reply-To: <87bkta8j9r.fsf@gmail.com> (Maxim Cournoyer's message of "Wed, 27 Jul 2022 15:09:36 -0400") Message-ID: <877d3y8hjj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 again, I just sent a first patch. Another idea would be to add a gexp compiler that would simply turn *unimplemented* into '*unimplemented* (i.e., quote it). I've never added a gexp compiler so I don't know how easy/difficult that is. Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 16:20:28 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 20:20:28 +0000 Received: from localhost ([127.0.0.1]:57097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGnW8-0008Iw-9w for submit@debbugs.gnu.org; Wed, 27 Jul 2022 16:20:28 -0400 Received: from mail-qt1-f171.google.com ([209.85.160.171]:38885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGnW5-0008Ib-Mj for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 16:20:27 -0400 Received: by mail-qt1-f171.google.com with SMTP id y9so13460436qtv.5 for <56799@debbugs.gnu.org>; Wed, 27 Jul 2022 13:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vhm1lpfnggZOkY+Gb+fg7CUXwukzH3pInabeyFb4t2c=; b=VNsiNvpFOB1kRo0Ut1i18vS7hCH7FwgumkG1rwfy+c0HdhlaJaxOUjN0ZJJjhw/92x 9p3O7ZCTJ8B/GUfi+Rb2NR7lvZL5e/Qfzz/EeIZxrKUP5g/2LNbvFezaJH0bRjqQfDDb RTNZY5iT783hv321iqdBNNTry6Bsdch7dmpt4N8KgDAjEFICb0ALvQpzsVaq33q+5JZL XIx/fqCiXQ1MLieiMEMJZPx8rSq5pXW3fDfxOxLJpszRp2fPKYqBei0W1Ei6Oixq6OrJ ud1TRMYl1lzrqK4qOKXB5T77BnvOr1B4/FHm1E6N7+DZgwH9xUoI5krMHTbRMjm65Err oEWg== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vhm1lpfnggZOkY+Gb+fg7CUXwukzH3pInabeyFb4t2c=; b=zL43YNSCAP8zJzWrlNVz9iSvqVCZvMpKr+JIMezg/dwyIvgGbw+LP3/s07qsynCz5+ WOghfvB/Adp0FqRbkuNR629Lh5nzChQv9fiGuGSOTp1ECqGp6Jzrdzs9SpFKkvFg/Ehv 81CCn/sU0Ho+n3ypX+QXt81b2llhOApFXDprOM2Y63Jh9H6pMOuKF0yqQ9yU1o4QbI3B th/4nqZmivBHdw7WzPlGgyhn3bwPrfSy55iX6ihlehgzcMIyJjlnjF4Kl3LiSpZP0wMN 7j631jQJJc1HGCAw7pGSiYZtxbMbLpi5/NHq9/8H3pfvFNqEn2y+5wtNQ3HaJqq3hjM9 hYlQ== X-Gm-Message-State: AJIora8KNRSiYVYKbq7a12MZ/7R7Rc51QieAe1JOJ4tIM/eghGluNEnm HUj2WFO0dZY3oo0Sn3AsqjNhPXnylF4= X-Google-Smtp-Source: AGRyM1uYuUX5S2EDNQIjkw0/71x+wtk7iGz+y2O0RniY9PuDW3llDYWO6YUf/0xOIdqXWYZuhsDfLA== X-Received: by 2002:ac8:7f92:0:b0:31f:3364:897e with SMTP id z18-20020ac87f92000000b0031f3364897emr16561644qtj.413.1658953219883; Wed, 27 Jul 2022 13:20:19 -0700 (PDT) Received: from localhost.localdomain (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id g11-20020a05620a40cb00b006af08c26774sm14716063qko.47.2022.07.27.13.20.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 13:20:19 -0700 (PDT) From: Maxim Cournoyer To: 56799@debbugs.gnu.org Subject: [PATCH v2] gexp: Handle *unspecified* as a gexp input. Date: Wed, 27 Jul 2022 16:20:10 -0400 Message-Id: <20220727202010.16970-1-maxim.cournoyer@gmail.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <877d3y8hjj.fsf@gmail.com> References: <877d3y8hjj.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: Maxim Cournoyer 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 (-) Fixes . * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encountering it. --- guix/gexp.scm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/guix/gexp.scm b/guix/gexp.scm index ef92223048..e05aed6f32 100644 --- a/guix/gexp.scm +++ b/guix/gexp.scm @@ -1380,6 +1380,8 @@ (define* (reference->sexp ref #:optional native?) #:output output))) (($ (? self-quoting? x)) (return x)) + (($ (? unspecified? x)) + (return (quote x))) (($ x) (raise (condition (&gexp-input-error (input x))))) (x -- 2.36.1 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 27 17:44:04 2022 Received: (at 56799) by debbugs.gnu.org; 27 Jul 2022 21:44:04 +0000 Received: from localhost ([127.0.0.1]:57154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGop2-0002I4-7g for submit@debbugs.gnu.org; Wed, 27 Jul 2022 17:44:04 -0400 Received: from michel.telenet-ops.be ([195.130.137.88]:57176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGoow-0002HP-Qc for 56799@debbugs.gnu.org; Wed, 27 Jul 2022 17:44:03 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by michel.telenet-ops.be with bizsmtp id 0Mjw2800320ykKC06MjwbT; Wed, 27 Jul 2022 23:43:57 +0200 Message-ID: <16e2cf89-bbfb-6336-0249-6af68afa3109@telenet.be> Date: Wed, 27 Jul 2022 23:43:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input. Content-Language: en-US To: Maxim Cournoyer , 56799@debbugs.gnu.org References: <877d3y8hjj.fsf@gmail.com> <20220727202010.16970-1-maxim.cournoyer@gmail.com> From: Maxime Devos In-Reply-To: <20220727202010.16970-1-maxim.cournoyer@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------wdvwX2Qc5ajcK7Z0TGi7U7e0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1658958237; bh=+V01nNzn3MzKR5XRAXoHSxbOeFzvhNxYpn3zlmOUGpo=; h=Date:Subject:To:References:From:In-Reply-To; b=AY3RikiaJLidu+gcG80nfcWVyc1FzQ4/HHMNM9acaTtTmlm4WsR61oIDM7DjvVj74 9xoYI9LfBmrX/XD2jXTuqFQFRr/SDkoPrYcBdi4bg411/ulq3xwrS4SCh2j0n6EOfo daQQ0O5jiUXVT7VztSP/w6KyCleDxizIDthmC4ri4GyWTDQdM7AyZhaqEDsyS23V/G NwX0zNP+qMJEPkjtbwCGJYSdxJ+sQhJ0Bc6vfZCsVegmVr9ZtIpsOeOGGNyxqmUkRm eFU5F1nrm4ZArady5h0idJyC+NnfxxQtFArk8Ge0MtHLkbB+HQUnxv0eA5CZZhRcvV cTWLADi68anAQ== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 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 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------wdvwX2Qc5ajcK7Z0TGi7U7e0 Content-Type: multipart/mixed; boundary="------------wWyJh08NsB2E80FhrlG2v4uH"; protected-headers="v1" From: Maxime Devos To: Maxim Cournoyer , 56799@debbugs.gnu.org Message-ID: <16e2cf89-bbfb-6336-0249-6af68afa3109@telenet.be> Subject: Re: bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input. References: <877d3y8hjj.fsf@gmail.com> <20220727202010.16970-1-maxim.cournoyer@gmail.com> In-Reply-To: <20220727202010.16970-1-maxim.cournoyer@gmail.com> --------------wWyJh08NsB2E80FhrlG2v4uH Content-Type: multipart/mixed; boundary="------------M6LDmVNzraowj3T8wif5rRue" --------------M6LDmVNzraowj3T8wif5rRue Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjctMDctMjAyMiAyMjoyMCwgTWF4aW0gQ291cm5veWVyIHdyb3RlOg0KDQo+IEZpeGVz IDxodHRwczovL2lzc3Vlcy5ndWl4LmdudS5vcmcvNTY3OTk+Lg0KPg0KPiAqIGd1aXgvZ2V4 cC5zY20gKGdleHAtPnNleHApWyp1bnNwZWNpZmllZCpdOiBRdW90ZSB2YWx1ZSB3aGVuIGVu Y291bnRlcmluZyBpdC4NCg0KSSByZWNvbW1lbmQgd3JpdGluZyBhIHRlc3QgY2FzZSAtLSB0 aGlzIHBhdGNoIGRvZXMgbm90IGFjdHVhbGx5IGRvIHRoYXQuDQoNCkluc3RlYWQsIGl0IHJl dHVybnMgdGhlIHN5bWJvbCB4Lg0KDQpJbiBhIC4vcHJlLWluc3QtZW52IGd1aXggcmVwbDoN Cg0KPiBzY2hlbWVAKGd1aXgtdXNlcik+ICx1c2UgKGd1aXgpDQo+IHNjaGVtZUAoZ3VpeC11 c2VyKT4gLG0gKGd1aXggZ2V4cCkNCj4gc2NoZW1lQChndWl4IGdleHApPiAsZW50ZXItc3Rv cmUtbW9uYWQNCj4gc3RvcmUtbW9uYWRAKGd1aXggZ2V4cCkgKGdleHAtPnNleHAgI34obGlz dCAjJCp1bnNwZWNpZmllZCopIA0KPiAieDg2XzY0LWxpbnV4IiAiYWFyY2g2NC1saW51eC1n bnUiKQ0KPiAkMSA9IChsaXN0IHgpDQpJIGRvbid0IGtub3cgd2hhdCBleGFjdCBzZW1hbnRp Y3MgeW91IGhhZCBpbiBtaW5kIGJ1dCBwcm9iYWJseSBub3QgdGhpcy4NCg0KR3JlZXRpbmdz LA0KTWF4aW1lLg0K --------------M6LDmVNzraowj3T8wif5rRue Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------M6LDmVNzraowj3T8wif5rRue-- --------------wWyJh08NsB2E80FhrlG2v4uH-- --------------wdvwX2Qc5ajcK7Z0TGi7U7e0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYuGxmwUDAAAAAAAKCRBJ4+4iGRcl7u1u AP49hLSlVuZFpolCAHys4OrKjthQv9Hr2sbah5g7jeopdQEA9gisOP1xlcpL/HdzP+HghqMX8NNl +/btPcICQwVd1QQ= =mTt8 -----END PGP SIGNATURE----- --------------wdvwX2Qc5ajcK7Z0TGi7U7e0-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 00:42:05 2022 Received: (at 56799) by debbugs.gnu.org; 28 Jul 2022 04:42:05 +0000 Received: from localhost ([127.0.0.1]:57359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGvLX-0006YR-Ch for submit@debbugs.gnu.org; Thu, 28 Jul 2022 00:42:05 -0400 Received: from mail-qv1-f53.google.com ([209.85.219.53]:46622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGvLR-0006Xt-R0 for 56799@debbugs.gnu.org; Thu, 28 Jul 2022 00:42:01 -0400 Received: by mail-qv1-f53.google.com with SMTP id x8so647256qvo.13 for <56799@debbugs.gnu.org>; Wed, 27 Jul 2022 21:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jVmR1vk8sDS5YtHz1jrfRiEhefQlwkHZIztFhRC9y54=; b=I/7FfBId79jaT89ZFgbJIjL4vVOl61/qJV83mHtlWNEK548kq8lO/iSo1KKzAC/+dN 0fkmnAAc/67KsoRigNYxhWJkG2lrEyOj+FS/AWZEDYY/uU10NfB2dH11zyYJa2ct29Gz nT5dG7ts0/NWH5Xhw3GUW1LUlzy7FBsC7Oj8q8ZoJ4UDlB/SCHbrBmJnv0Ywk4RirTfm PdlnVNOwyKoMhYt3qdUry0uTgWB1nuSIwpX/qHZoTZRal6ZZdaa/7lpXYiOT6rnSHSqa EzVxmTNBMXwi+NYeXP6q3Y1Cz0oNGz/wBuv+uRNsJmPN8RHQPFRmXWR2XE5omLvhNR0W SPGg== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jVmR1vk8sDS5YtHz1jrfRiEhefQlwkHZIztFhRC9y54=; b=fNSqGVWmxxQZ2TlmRBBaQ5DbtKBf+72/C15XCPJ/qAM19dmy0ZthyQbBqPWn0zQU9m AwnfuCcXsSki/hZoiihcJCBWqlgbUgQT1g+/QT2Ft+yrDzuM0rVtjlFEOYEbd030sq2B XdKt6ZBxTLLBrVLnq69MoUawxg0D4HZFRkxwDFfnQ33HpPOy9nJCqQietlAKQFZWaSv9 boSac7OPUXH+uJEamXyJdWOvnvb4qXzfHyK9x2QTGM/e7l36x96+JlOaUi+dkZJqpWXM KmmHFGzmFN9H3k1ypA1FixD3/QBSRbFx+JSibSUyiicFtPp4ROXn9+vmbti4HdVFjTVt MH3w== X-Gm-Message-State: AJIora9dKYeXtamhFvgaxja9gsc3ca8E0EEVCdeahg9KBHp30vTkO/bg H87U6TtoNFmcDiu3M9sYHlQWOXRlBkU= X-Google-Smtp-Source: AGRyM1uQ2p2LTZQI0ww+Bi3QPEStA7pPOFz7lLwrm6rkRgc7apH0Ev/zmLy1hdxPctYp4hGrO27MAg== X-Received: by 2002:a05:6214:3010:b0:473:626a:5526 with SMTP id ke16-20020a056214301000b00473626a5526mr22076426qvb.1.1658983311997; Wed, 27 Jul 2022 21:41:51 -0700 (PDT) Received: from localhost.localdomain (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id y8-20020a05620a44c800b006b5c5987ff2sm15761784qkp.96.2022.07.27.21.41.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 21:41:51 -0700 (PDT) From: Maxim Cournoyer To: 56799@debbugs.gnu.org Subject: [PATCH v3] gexp: Handle *unspecified* as a gexp input. Date: Thu, 28 Jul 2022 00:41:44 -0400 Message-Id: <20220728044144.15693-1-maxim.cournoyer@gmail.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <877d3y8hjj.fsf@gmail.com> References: <877d3y8hjj.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: Maxim Cournoyer 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 (-) Fixes . * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encountering it. --- guix/gexp.scm | 2 ++ tests/gexp.scm | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/guix/gexp.scm b/guix/gexp.scm index ef92223048..fe47a116f6 100644 --- a/guix/gexp.scm +++ b/guix/gexp.scm @@ -1380,6 +1380,8 @@ (define* (reference->sexp ref #:optional native?) #:output output))) (($ (? self-quoting? x)) (return x)) + (($ (? unspecified?)) + (return '*unspecified*)) (($ x) (raise (condition (&gexp-input-error (input x))))) (x diff --git a/tests/gexp.scm b/tests/gexp.scm index 07e940ffdc..cad139fde7 100644 --- a/tests/gexp.scm +++ b/tests/gexp.scm @@ -1128,6 +1128,12 @@ (define (matching-input drv output) (run-with-store %store (lower-gexp #~(foo #$+))))) +(test-equal "lower-gexp, *unspecified* input" + '(*unspecified*) + (lowered-gexp-sexp + (run-with-store %store + (lower-gexp #~(#$*unspecified*))))) + (test-equal "lower-gexp, character literal" '(#\+) (lowered-gexp-sexp -- 2.36.1 From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 00:55:37 2022 Received: (at 56799) by debbugs.gnu.org; 28 Jul 2022 04:55:37 +0000 Received: from localhost ([127.0.0.1]:57363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGvYe-0006xJ-Om for submit@debbugs.gnu.org; Thu, 28 Jul 2022 00:55:37 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:41970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oGvYb-0006x1-74 for 56799@debbugs.gnu.org; Thu, 28 Jul 2022 00:55:35 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id E30D162C8B; Thu, 28 Jul 2022 04:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1658984125; bh=z7U8vymwcJd36EfLSgo/GmGb8lHvDTQkXeAsPS1D5IM=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=U3GYB8RCF3a+ItlMDqmU/e0sBTrD4zKZFKWgOiNrO43ul89z4HjSFWcFJG6uVFx5f 3E0A+4SwqKANAnl8RIqV1TEWP4JlO4S7Fedg/mULa2Fr6/9jWKiCzGT1VZycTC5IZC rD2pRM0boPUUDYgU0C6vqe+1cVwT/2fgBqC6HJoT1+iEY/y+hcxR1rHrVO/DPoYIhG Glg7r0K8Vv3BOf/eO+1NFvOPkHaeVPC6Fr/Zd++o2kDLBUook53oJ1z924HE9tBhV3 IPBZ5GSFwUJ9AP95SS+BPq80bKeDT5RqNNDRC5aO7PALxBcYfQse7KqGr1ik4CcCjf PKlfwwaSFzQTw== X-Virus-Scanned: Debian amavisd-new at emo09-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo09-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne8beH5KaNyB; Thu, 28 Jul 2022 04:55:25 +0000 (UTC) Received: from localhost (m83-185-33-237.cust.tele2.se [83.185.33.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 00C1762C75; Thu, 28 Jul 2022 04:55:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1658984125; bh=z7U8vymwcJd36EfLSgo/GmGb8lHvDTQkXeAsPS1D5IM=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=U3GYB8RCF3a+ItlMDqmU/e0sBTrD4zKZFKWgOiNrO43ul89z4HjSFWcFJG6uVFx5f 3E0A+4SwqKANAnl8RIqV1TEWP4JlO4S7Fedg/mULa2Fr6/9jWKiCzGT1VZycTC5IZC rD2pRM0boPUUDYgU0C6vqe+1cVwT/2fgBqC6HJoT1+iEY/y+hcxR1rHrVO/DPoYIhG Glg7r0K8Vv3BOf/eO+1NFvOPkHaeVPC6Fr/Zd++o2kDLBUook53oJ1z924HE9tBhV3 IPBZ5GSFwUJ9AP95SS+BPq80bKeDT5RqNNDRC5aO7PALxBcYfQse7KqGr1ik4CcCjf PKlfwwaSFzQTw== From: bokr@bokr.com Date: Thu, 28 Jul 2022 06:55:06 +0200 To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: <20220728045506.GA9725@LionPure> References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87fsim8l17.fsf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name, Tobias Geerinckx-Rice 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, On +2022-07-27 14:31:32 -0400, Maxim Cournoyer wrote: > Hi, > > Tobias Geerinckx-Rice writes: > > > Hi Maxim, > > > > Maxim Cournoyer 写道： > >> I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449 to > >> use > >> 'unspecified (the symbol) instead of *unspecified*, which *can* be > >> serialized without any fuss in gexps. > > > > Bah. Could we provide our own reader? > > > > I'd much rather this be addressed in Guile (or failing that, > > transparently by Guix) than have to deal with some magical > > symbol. IIRC that was the argument for using *unspecified* in the > > first place, and I think it makes sense. > > > > This looks more like an unexplored oversight than a well-reasoned > > restriction to me. > > This was my original impression, but thinking more about it, it became > apparent that *unspecified* is well, unspecified and shouldn't be relied > on by people to be something well defined. For some background reading, > see [0]. So it seems wrong in Scheme to actively set things to > *unspecified*, and give a specific meaning to that. > > I think the semantic of the language is that it is to be used as the > lack of a return value from a procedure or syntax, e.g.: > > (unspecified? (if #f 'one-arm-if)) -> #t > > Having 'unspecified?' even defined in Guile seems to go against that > idea; perhaps because Wingo themselves seems to disagree in [0]. > > I'm also thinking 'unspecified being too close to *unspecified* is > probably going to cause confusion down the line. Reverting to the > originally used 'disabled may be the lesser evil. > > Other thoughts? > > Thanks, > > Maxim > > [0] https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified-values > > > Lots of systems are dealing with this issue, it seems, judging from [1] https://en.wikipedia.org/wiki/Bottom_type I think the problem is you really need a tuple to return both data and metadata unambiguously from anything that produces a result (or not, which is a result). Something like read-delimited with the 'split option, or using catch. Personally, if I were designing a language :), my goal would be to have nothing unspecified, and no undefined behaviour outside of physical failures ;-) *unspecified* seems me like an ok word for the unasserted/high-impedance state of tri-state memory address bus electronic logic, but IMO the example above --8<---------------cut here---------------start------------->8--- > (unspecified? (if #f 'one-arm-if)) -> #t --8<---------------cut here---------------end--------------->8--- is not nice. (A nit, but For one thing "specified?" ought to be the question IMO, if you are ging to have that concept, not "unspecified?" :) What about using characters from some private upper unicode section to represent various kinds of unspecified things? E.g., as guile named chars, #\unspecified_function_retval #\unspecified_function_error #\unspecified_macro_err #\unspecified_exception #\nil or #\not_an_object -- or #\nao -- can't use #\n :) #\paradox -- e.g., (eval-nl-string "this sentence is lying") #\nonsense -- e.g. when a question is based on false premises (eval-nl-string "Bob is bareheaded: Bob, is your hat too tight?") Hm, one could argue that (+ "ab" "cd") could be based on the false premise that + was overloaded like --8<---------------cut here---------------start------------->8--- scheme@(guile-user) [1]> (let*( (+ string-append) (sum (+ "ab" "cd"))) sum) $8 = "abcd" --8<---------------cut here---------------end--------------->8--- and if it wasn't, should return #\nonsense :) (though maybe as part of the exception, which is practical for debugging etc :) #\ #\guix_bottom -- a private unicode rather than U+22A5 which could be returned as a valid character value by some functon. --8<---------------cut here---------------start------------->8--- $ echo -en "\u22a5"|unicode-info "⊥": glyph codepoint .....int name... _⊥_ +U0022a5 8869 UP TACK --8<---------------cut here---------------end--------------->8--- Well, hope you can extract something useful from the above :) BTW, I didn't get far via the link [0] :( --8<---------------cut here---------------start------------->8--- 🤖 Hungry for data? 🤖 As you guessed, this page is to confirm your affiliation to the human race. about - legalese Loading... --8<---------------cut here---------------end--------------->8--- Ok machine, you identified me as human, and kept me out. Happy? No, I know, machines can only fake that. -- Regards, Bengt Richter From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 06:26:07 2022 Received: (at 56799) by debbugs.gnu.org; 28 Jul 2022 10:26:07 +0000 Received: from localhost ([127.0.0.1]:57697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH0iU-0000C9-Mw for submit@debbugs.gnu.org; Thu, 28 Jul 2022 06:26:07 -0400 Received: from albert.telenet-ops.be ([195.130.137.90]:59358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH0iS-0000C0-JN for 56799@debbugs.gnu.org; Thu, 28 Jul 2022 06:26:05 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by albert.telenet-ops.be with bizsmtp id 0aS12800720ykKC06aS1Zi; Thu, 28 Jul 2022 12:26:02 +0200 Message-ID: Date: Thu, 28 Jul 2022 12:26:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: bokr@bokr.com, Maxim Cournoyer References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <20220728045506.GA9725@LionPure> From: Maxime Devos Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic In-Reply-To: <20220728045506.GA9725@LionPure> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------nh0yi0j04GzjK1bQ5gzHekkr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1659003962; bh=xhMwXbtwOSkUDuGGOYD1N/FA3PeiCwjulGrQvDiYlAY=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=d7b3em5oGQGOv8Z0tRVpuFxwg4+oMhEvnt/bjc8L2c13XpYEFsdFEXDCBNVdlwP7L 9jV/GF3YX0eQ0M6wX4a613jBC7CcjMgdWT/mGJTBDthaAgEoGo4KMr0d3PV+UMCEOt YFvNQon7Ge3OLSrOv7NiS15vdBiYLF3v8qHBc1I6jit7gLI+m55sRVww5/kH0f0OFh Go0UBSJRYM+hkvpItaUolv+5SgpVCZDokqA+raw5WfvW9kgq12qv3crFVww3LOeYQ1 w/+QzuA8/qduUDk08HlmFyHDDuskRCF/FTJ0ORlWFGLQT9Q/kHxdvhCQb9y1eyEB5W 8VGFzLytiBjhg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name, Tobias Geerinckx-Rice 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 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nh0yi0j04GzjK1bQ5gzHekkr Content-Type: multipart/mixed; boundary="------------JfVKqMKliTFLSNdIEmlNuMin"; protected-headers="v1" From: Maxime Devos To: bokr@bokr.com, Maxim Cournoyer Cc: 56799@debbugs.gnu.org, attila@lendvai.name, Tobias Geerinckx-Rice Message-ID: Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <20220728045506.GA9725@LionPure> In-Reply-To: <20220728045506.GA9725@LionPure> --------------JfVKqMKliTFLSNdIEmlNuMin Content-Type: multipart/mixed; boundary="------------785fQ0i13ZkShp6EYKUjt5xB" --------------785fQ0i13ZkShp6EYKUjt5xB Content-Type: multipart/alternative; boundary="------------ZFCmXJGQGFal1bgURxnYJqIA" --------------ZFCmXJGQGFal1bgURxnYJqIA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAyOC0wNy0yMDIyIDA2OjU1LCBib2tyQGJva3IuY29tIHdyb3RlOg0KPiBMb3RzIG9m IHN5c3RlbXMgYXJlIGRlYWxpbmcgd2l0aCB0aGlzIGlzc3VlLCBpdCBzZWVtcywganVkZ2lu ZyBmcm9tDQo+IFsxXWh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0JvdHRvbV90eXBl DQoNCkkgZG9uJ3QgdGhpbmsgaXQncyBhIGJvdHRvbSB0eXBlIC0tICp1bnNwZWNpZmllZCog X2lzXyBhIHZhbHVlLCBzbyBpZiB3ZSANCmFzc2lnbiBhIHR5cGUgdG8gaXQsIGl0IGlzIGlu aGFiaXRlZCwgYW5kIGhlbmNlIG5vdCBhIGJvdHRvbSB0eXBlLiBJDQoNCj4gV2hhdCBhYm91 dCB1c2luZyBjaGFyYWN0ZXJzIGZyb20gc29tZSBwcml2YXRlIHVwcGVyIHVuaWNvZGUgc2Vj dGlvbg0KPiB0byByZXByZXNlbnQgdmFyaW91cyBraW5kcyBvZiB1bnNwZWNpZmllZCB0aGlu Z3M/IEUuZy4sDQo+IGFzIGd1aWxlIG5hbWVkIGNoYXJzLA0KPg0KPiAjXHVuc3BlY2lmaWVk X2Z1bmN0aW9uX3JldHZhbA0KPiAjXHVuc3BlY2lmaWVkX2Z1bmN0aW9uX2Vycm9yDQo+ICNc dW5zcGVjaWZpZWRfbWFjcm9fZXJyDQo+ICNcdW5zcGVjaWZpZWRfZXhjZXB0aW9uDQogwqBz dXBwb3NlIHlvdSBjb3VsZCBzdWJkaXZpZGUgdGhlICp1bnNwZWNpZmllZCogdmFsdWUsIGJ1 dCB3aHkgY2hhcmFjdGVycz8NCg0KSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG86DQoN CiAgKiBncmFkdWFsbHkgbW92ZSBhd2F5IGZyb20gKnVuc3BlY2lmaWVkKiB0byAodmFsdWVz KQ0KICAqIGFuZCB0aGlzIHdheSwgZ3JhZHVhbGx5IGNoYW5nZSB0aGUgbWVhbmluZyBvZiAq dW5zcGVjaWZpZWQqIGZyb20gImFuDQogICAgdW5zcGVjaWZpZWQgdmFsdWUiIHRvICdhbiBh dG9tIHlvdSBjYW4gZG8gd2l0aCBhcyB5b3Ugd2FudCINCiAgKiBhZnRlciB0aGlzLCB1bnNw ZWNpZmllZD8gYW5kIG1ha2luZyAjPHVuc3BlY2lmaWVkPiByZWFkYWJsZSBieSB0aGUNCiAg ICByZWFkZXIgYXJlbid0IHdlaXJkIGFueW1vcmUNCg0KdGhvdWdoIG1vcmUgc29tZXRoaW5n IGZvciBndWlsZS1kZXZlbEAgSSBzdXBwb3NlLg0KDQpHcmVldGluZ3MsDQpNYXhpbWUNCg0K --------------ZFCmXJGQGFal1bgURxnYJqIA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 28-07-2022 06:55, bokr@bokr.com wrote:
Lots of systems are dealing =
with this issue, it seems, judging from
[1] https://en.wikipedia.org/wiki/B=
ottom_type

I don't think it's a bottom type -- *unspecified* _is_ a value, so if we assign a type to it, it is inhabited, and hence not a bottom type. I 

What about using character=
s from some private upper unicode section
to represent various kinds of unspecified things? E.g.,
as guile named chars,

#\unspecified_function_retval
#\unspecified_function_error
#\unspecified_macro_err
#\unspecified_exception
=C2=A0suppose you could subdivide the *unspecified* value, but why characters?

I think it would be better to:

  • gradually move away from *unspecified* to (values)
  • and this way, gradually change the meaning of *unspecified* from "an unspecified value" to 'an atom you can do with as you want"
  • after this, unspecified? and making #<unspecified> readable by the reader aren't weird anymore

though more something for guile-devel@ I suppose.

Greetings,
Maxime

--------------ZFCmXJGQGFal1bgURxnYJqIA-- --------------785fQ0i13ZkShp6EYKUjt5xB Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------785fQ0i13ZkShp6EYKUjt5xB-- --------------JfVKqMKliTFLSNdIEmlNuMin-- --------------nh0yi0j04GzjK1bQ5gzHekkr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYuJkOAUDAAAAAAAKCRBJ4+4iGRcl7qiF AP9Xl1LqKDm5KPwgEcLWXiLBaRaA0UIydtMSQq9LzsRiKQD8D8LSdV09C7C5c2dyy0aYGKIQt/MK w8L3G5dGZfFaygw= =fxpW -----END PGP SIGNATURE----- --------------nh0yi0j04GzjK1bQ5gzHekkr-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 10:59:02 2022 Received: (at 56799) by debbugs.gnu.org; 28 Jul 2022 14:59:02 +0000 Received: from localhost ([127.0.0.1]:59250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH4yc-0000Ml-4g for submit@debbugs.gnu.org; Thu, 28 Jul 2022 10:59:02 -0400 Received: from mail-qt1-f179.google.com ([209.85.160.179]:45006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH4yZ-0000MH-KO for 56799@debbugs.gnu.org; Thu, 28 Jul 2022 10:59:00 -0400 Received: by mail-qt1-f179.google.com with SMTP id r21so1272278qtn.11 for <56799@debbugs.gnu.org>; Thu, 28 Jul 2022 07:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Nwzoq23udU6iZmt19b3tuMkIXtqoLFht7y8DWx9YTjw=; b=VGrsfLa70MJab+2fHO5u19868TDfVaFv6nFbg2uYoaySANI/gmyTcgwlktlJ58swdX dmNZH7WAA7L0c+12By//9bVZVIBDyv4McymouJU21nBsJrqsVpcDyfgmnIyhu7bnf7zt Ypgjc1pv0QwVPHXpIZ9DKWsvFdLorpOqGRGr9APRpHMsmXIWxq/SiNhEzw7DiqqEXAQb UNMBLLc5w2svhpHmj/xsu4S7Kt7+H1Flj0N1SI7rhmCxtUXp1JU1dTq5a+IWleudP/JT m04gH/aHEyOoL0Psu9DooCoKdAp6q+2tiV19zfOZ8ibXC26fj6E7erq+uozwf6TqmYk+ /SOQ== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Nwzoq23udU6iZmt19b3tuMkIXtqoLFht7y8DWx9YTjw=; b=ZXm+1hYU2pLz2xdi/ns8RCUEUC6pRF6IwtMPLBFJ76oc3E/adS29S33myex3xBqEEw nvvba9jgLstvJE5U3bxAtsrlKD1BYFQ/TwFN1uOIPhPV73yQHEzCZwcYeSobpXuEox6T Tj6mZc1JAQpduy5WI2ccGRVBjgHsz37bjb7FR0e1w+sjueuYfm7Um04mvNt7P0rTw4/d d1AQgeVKR4o9u+eU5IXjzGUIE1XIKEBaD3MqoOohAlzr06pEt+3444EHJqyAgkMeE8Yv Ue4Pb5NUc/H2/9uEsuDu/YBaHXA3CzY/kCHxZ7nHPdTEpfwRyp0Jz3d3m4FtPN30iNA/ ubng== X-Gm-Message-State: AJIora8l0QpRnWHrboyva1sjfP76bbFT3qu+HBc1unuZjMOtaXaPKZx3 9hTErfPT3py4w7PXGmWaTliOo0TvsEk= X-Google-Smtp-Source: AGRyM1sXeMA3ZnTJlRSLtQC83w+HbbJWICUw7H+fTNOmmVma6afs7sVLBKBxqUz7lkz2dgY45pq8Dw== X-Received: by 2002:ac8:5d94:0:b0:31f:1e7b:7d9b with SMTP id d20-20020ac85d94000000b0031f1e7b7d9bmr22487915qtx.205.1659020333746; Thu, 28 Jul 2022 07:58:53 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id d7-20020a05620a240700b006a3325fd985sm675968qkn.13.2022.07.28.07.58.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 07:58:53 -0700 (PDT) From: Maxim Cournoyer To: Maxime Devos Subject: Re: bug#56799: [PATCH v2] gexp: Handle *unspecified* as a gexp input. References: <877d3y8hjj.fsf@gmail.com> <20220727202010.16970-1-maxim.cournoyer@gmail.com> <16e2cf89-bbfb-6336-0249-6af68afa3109@telenet.be> Date: Thu, 28 Jul 2022 10:58:52 -0400 In-Reply-To: <16e2cf89-bbfb-6336-0249-6af68afa3109@telenet.be> (Maxime Devos's message of "Wed, 27 Jul 2022 23:43:55 +0200") Message-ID: <87r125707n.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@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, Maxime Devos writes: > On 27-07-2022 22:20, Maxim Cournoyer wrote: > >> Fixes . >> >> * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encountering it. > > I recommend writing a test case -- this patch does not actually do that. > > Instead, it returns the symbol x. > > In a ./pre-inst-env guix repl: > >> scheme@(guix-user)> ,use (guix) >> scheme@(guix-user)> ,m (guix gexp) >> scheme@(guix gexp)> ,enter-store-monad >> store-monad@(guix gexp) (gexp->sexp #~(list #$*unspecified*) >> "x86_64-linux" "aarch64-linux-gnu") >> $1 = (list x) > I don't know what exact semantics you had in mind but probably not this. Indeed. Fixed in v3 (which includes a test). Thanks! Maxim From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 11:09:57 2022 Received: (at 56799) by debbugs.gnu.org; 28 Jul 2022 15:09:57 +0000 Received: from localhost ([127.0.0.1]:59276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH59B-0000hr-GR for submit@debbugs.gnu.org; Thu, 28 Jul 2022 11:09:57 -0400 Received: from mail-qv1-f54.google.com ([209.85.219.54]:41798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH597-0000ha-UD for 56799@debbugs.gnu.org; Thu, 28 Jul 2022 11:09:55 -0400 Received: by mail-qv1-f54.google.com with SMTP id i7so1602734qvr.8 for <56799@debbugs.gnu.org>; Thu, 28 Jul 2022 08:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=OhucthgIqhGEVjDqvl/j3bULdXcwp8iotwSL6jKpxvg=; b=jyY4oTl18Rw2oajY9rnc/YkuMTCjlByWzlfuMKLzVgFIde2Yr0i7SCTAFxqc+D0exe fYIB1DPjAn00AdV7SF6D+iZvV8l4lac3amnTZcw2oUz/EZVKOFKXuWZgAEBXvyXghddX J6Tw9dSprd3llTlNL6yeXtlfJ/DlY5HddNKWVDxjO8Kt1gz2EyPvMHWKwSg+uFHQtbvc 2VWidjazJpgpnKwGyAHqpmDE0mK1KpjAaAwE+CU+1SIVlDq9lENSS2E1h/5CvFOe61R0 4r2z04c/fhg8QfTaCxD26DT6lmzSz2Zjw4qDaWeUKuWwugtgyOTLe2suHTi06YN0DJQm XOww== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=OhucthgIqhGEVjDqvl/j3bULdXcwp8iotwSL6jKpxvg=; b=MvOMbE0SsK/KHwc+H54byIa4c6eXOTbejvrd2tFEAT1iTkUeYaM8Z+bnWmWWktqVXY 8a9ObKd7YeP1sg9pxUpxL9+czbgj41ewbtmFD+YHoxQx29DVv++IylFDLSE8DH9sIhqq 0Ffv60Q/ZmwtgOzdnTeOLRTtYN/VLzn+T3/6zKEMzVJPgE9AL3ci8fQM+vpG1a0Aglgq mG8nuIQWZ7BZhgYPsiUeT5jhmgKXMHhCo5g6lEo8LHf+GGki0iMJ5v1vhGbl168pnKVd LtUMUcOhD2LbbjrOuzIrUjM5QWyeNMmqFdTpctTbGQHyikVL9C3ZiCer9re6m9brPhT1 b/kg== X-Gm-Message-State: AJIora+VRtIl1+k4QybhmcphdRn01C9dpBdZ5o70tbD6eA9qAJeccYsH awPnQ/8EmZa8YaXZ7F+v3SQ= X-Google-Smtp-Source: AGRyM1v3jQK+VWfTItsjQ9tWw5wBfgMg6hBxi1KY1KVjRAyNs5JqoXTxcu9IfJ21c9ta2nlS2yoAHQ== X-Received: by 2002:a0c:8c0f:0:b0:473:a6f7:aa5b with SMTP id n15-20020a0c8c0f000000b00473a6f7aa5bmr23683198qvb.23.1659020988350; Thu, 28 Jul 2022 08:09:48 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id cm12-20020a05622a250c00b0031eaabd2117sm594774qtb.12.2022.07.28.08.09.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 08:09:47 -0700 (PDT) From: Maxim Cournoyer To: Maxime Devos Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <20220728045506.GA9725@LionPure> Date: Thu, 28 Jul 2022 11:09:46 -0400 In-Reply-To: (Maxime Devos's message of "Thu, 28 Jul 2022 12:26:00 +0200") Message-ID: <87mtct6zph.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name, Tobias Geerinckx-Rice , bokr@bokr.com 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 Maxime, Maxime Devos writes: [...] > I think it would be better to: > > * gradually move away from *unspecified* to (values) > * and this way, gradually change the meaning of *unspecified* from "an > unspecified value" to 'an atom you can do with as you want" > * after this, unspecified? and making # readable by the > reader aren't weird anymore Or perhaps simply introduce a #none or other special syntax similar to None in Python, that would serve a different purpose that *unspecified*, and be orthogonal to it. It seems that'd be less confusing and simpler. Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 28 11:15:32 2022 Received: (at 56799) by debbugs.gnu.org; 28 Jul 2022 15:15:32 +0000 Received: from localhost ([127.0.0.1]:59286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH5Ea-0000sG-Js for submit@debbugs.gnu.org; Thu, 28 Jul 2022 11:15:32 -0400 Received: from mail-qv1-f49.google.com ([209.85.219.49]:37631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH5EY-0000s1-Rn for 56799@debbugs.gnu.org; Thu, 28 Jul 2022 11:15:31 -0400 Received: by mail-qv1-f49.google.com with SMTP id m10so1629162qvu.4 for <56799@debbugs.gnu.org>; Thu, 28 Jul 2022 08:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=hHXU5qMSpv7UG5ksb5EzjLABlOOogvJEh3ujwsDKkSA=; b=FSS4Zba1e1jeC5B6sPukCaM13nPlFd3wlbPfeeCAZk2UWvk/l8GLFZ1Zt49oAUaR2O /I/1vopOJLbimmOViKVPt750j1XSAVvhCJ3un0DPjrpDkGhLc/xDRnS7vKS9DI0NC58A INFTIlo/GMSV5ghUlc1Uf3y29p7DBXp0ywkEZw96tX4e1nhnXGZVMf7YUf/ubfSNUNgb zGzHZJiS7VICSpw1jp9I+t3CzgfTCuXtBdHIPZgYYmk1i+1UDZD82puE9t51k7jY/Ksq wg3XenBcTf+n7Dr1qCIRJ6GFtwJf3+MsL39VgmC9Yaz3EDk3oDxUlIvHHFMtJV1WD5ZR mW5Q== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=hHXU5qMSpv7UG5ksb5EzjLABlOOogvJEh3ujwsDKkSA=; b=kzPv4nDFosL92KoldDQwfWr1NYlsiji0uOizllKK4Yn6XGwUduuRI9hVBX8aql90S0 b0GIG18/W7FIO45ts18iUkZQafqP9+Tlk52HLKfjLB2Ag9EvQVwdfRMU3hucAr5W6AgG Y6u74x6EvSqnrJM3eHxkqh/ZPeFai2VkjTSZFlA5b5RXBd8YWOT13FQkqBnuXvqLQ2mT 9160WpS+S6tQZ5aPCeKZBwEcEbmy36/lN/1MkcNGRs0lmziR2DGQ4VT7GaAgAhC5+cT1 NzABbR4pQFLEe2dHM860zytb/ZcQvWqqxIorMpZgy85PLdQjjNc8dDv3oyDnVIlw7F9h //IA== X-Gm-Message-State: AJIora/RlLEVwx/jL8y0cq8fU30ZI567gKIx0/id/i/rQJ9yQyObyaGj 4y9qpDZcyRYZoJCQmgeidJeKJ6c1iCU= X-Google-Smtp-Source: AGRyM1soz8/NQ/PD5F9h9c1A3GSEIbHPvN3TE9NpMpD0LccWfCYNMy0h1aSbHWggN7vnWVt8tpIhKQ== X-Received: by 2002:a05:6214:5185:b0:472:f9b0:cbc6 with SMTP id kl5-20020a056214518500b00472f9b0cbc6mr24147390qvb.92.1659021324921; Thu, 28 Jul 2022 08:15:24 -0700 (PDT) Received: from hurd (dsl-10-148-58.b2b2c.ca. [72.10.148.58]) by smtp.gmail.com with ESMTPSA id u17-20020a05620a455100b006b5cb5d2fa0sm737595qkp.1.2022.07.28.08.15.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 08:15:24 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> Date: Thu, 28 Jul 2022 11:15:23 -0400 In-Reply-To: (Attila Lendvai's message of "Wed, 27 Jul 2022 18:27:13 +0000") Message-ID: <87ilnh6zg4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Tobias Geerinckx-Rice 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 Attila, [...] > i need to run now, and i'll be offline for a week or two. i can't look > the example in depth now, but my gut instinct says that it's a bug if > *unspecified* reaches any GExp machinery. I don't think it's reasonable to burden users with normalizing their G-exp input data, where *unspecified* may appear in nested data structures (such as used by the jami-service-type: jami-accounts has maybe fields end is used as a nested data type to jami-configuration). I think v3 of this patch enables us to continue with our current ways and is a non-invasive change, so I'll merge it soon if there are no objections. Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 01:08:45 2022 Received: (at 56799) by debbugs.gnu.org; 1 Aug 2022 05:08:45 +0000 Received: from localhost ([127.0.0.1]:39031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oINfY-0000m4-Q0 for submit@debbugs.gnu.org; Mon, 01 Aug 2022 01:08:45 -0400 Received: from mail-qt1-f176.google.com ([209.85.160.176]:33723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oINfT-0000lo-FX for 56799@debbugs.gnu.org; Mon, 01 Aug 2022 01:08:43 -0400 Received: by mail-qt1-f176.google.com with SMTP id u12so7317124qtk.0 for <56799@debbugs.gnu.org>; Sun, 31 Jul 2022 22:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version; bh=4aQ+Z5zmAG1C1yz4EzVJ6tlsNd14d3BCsdn/lnBGuwU=; b=A5veN6VCRYaa6sovJlF2jD9ZKo74xUfTtJ0HqkggAHh29gPh0X6rQp27mk4byWfOTO BT6+zRxLPh9yL9JlYr+LkakGmpv1ex08dnjwQvd86Ur9ZAvrwx8G7AYlDs0lAl828Eo6 WzFW6baG5hDLVgZo0Fs6OGr1u0pqkgO3U7AnMB2VqWu19xXzdiPwsFJ+HmvMgZDXAfsF qIi/S4z+KpXWtY8bbATOoU03L9EOdJv8mtQENvQKG+4N66VfBj09hrTEGC5GOKepdEk5 pim5RMJJGqNdT6rAJbu7buBK8GeeXIEOM3JNuqqBIuk8FAzJLEvIzMIfBO12oZchTigy FU5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=4aQ+Z5zmAG1C1yz4EzVJ6tlsNd14d3BCsdn/lnBGuwU=; b=friUQtEft5vXIPvXK4MKwKCjpZV3RuHv8COkfmnhiErb2f+kXeKaCeDA8+nF5TeZhW qt7cPGs4A2O6oGnoMqYxprAc26Rh4cp76aW8DCaQp+uDlSsqkhOcR1M21IrY3XaVDYuM T02O5flYORBhf7hBKXnPoIyPTriNJopnSg9fnDOnTG05mrsqSFcIksudW3dv57/iW3Es HAqDARXs7BOkS5TYwtzCfHNu0LfOfxrjqxbJ7OTlfvL0yKO1QDEhE0nB3HXW+yQFY5RV WPekrM1pGpSB3dzU9FdUY+Y8Lf2omgwT3Y16Jqm50/4scS7TOy7LaE/+xhgok48U5crP sg7w== X-Gm-Message-State: AJIora9pXhy/Irgv3gy7ZUZLN5ZNyOZARCHo5C+GqatELFC8PbNyBLhe 7UXILHxWWkyW/4yWUcpAfpbIhNFfM1g= X-Google-Smtp-Source: AGRyM1vhoovfRcdIkVYyDHDVkjHZZJtKJthGO7atH4R7qqITxPPi+JPZx4BUQueiSejX7GKO2gG7lg== X-Received: by 2002:ac8:5949:0:b0:31e:f363:989 with SMTP id 9-20020ac85949000000b0031ef3630989mr12843121qtz.483.1659330513050; Sun, 31 Jul 2022 22:08:33 -0700 (PDT) Received: from hurd (dsl-158-240.b2b2c.ca. [66.158.158.240]) by smtp.gmail.com with ESMTPSA id x21-20020a05620a0b5500b006a793bde241sm7473635qkg.63.2022.07.31.22.08.32 for <56799@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Jul 2022 22:08:32 -0700 (PDT) From: Maxim Cournoyer To: 56799@debbugs.gnu.org Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <877d3y8hjj.fsf@gmail.com> <20220728044144.15693-1-maxim.cournoyer@gmail.com> Date: Mon, 01 Aug 2022 01:08:31 -0400 In-Reply-To: <20220728044144.15693-1-maxim.cournoyer@gmail.com> (Maxim Cournoyer's message of "Thu, 28 Jul 2022 00:41:44 -0400") Message-ID: <87mtco4kkw.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 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 (-) --=-=-= Content-Type: text/plain Hi, Maxim Cournoyer writes: > Fixes . > > * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encountering it. Sadly, this doesn't fix the jami service when using a partially defined jami-account as part of the jami-configuration; the error is: --8<---------------cut here---------------start------------->8--- In procedure for-each: Wrong type argument: *unspecified* --8<---------------cut here---------------end--------------->8--- Here's what the generated shepherd-jami.scm file look like: --8<---------------cut here---------------start------------->8--- #:start (lambda args (define (delete-file-recursively/safe file) (let ((parent-directory (dirname file))) (if (eq? (quote symlink) (stat:type (stat parent-directory))) (error "abnormality detected; unexpected symlink found at" parent-directory) (delete-file-recursively file)))) (when #t (catch #t (lambda () (for-each (cut delete-file-recursively/safe <>) (quote ("/var/lib/jami/.cache/jami" "/var/lib/jami/.config/jami" "/var/lib/jami/.local/share/jami" "/var/lib/jami/accounts")))) (lambda args #t)) (let* ((accounts-dir "/var/lib/jami/accounts/") (pwd (getpwnam "jami")) (user (passwd:uid pwd)) (group (passwd:gid pwd))) (mkdir-p accounts-dir) (chown accounts-dir user group) (for-each (lambda (f) (let ((dest (string-append accounts-dir (basename f)))) (copy-file f dest) (chown dest user group))) (quote ("/gnu/store/14flr53fr0hs7mzfwn93kmyzrnb3fhjz-dummy-jami-account.gz"))))) (define daemon-pid ((make-forkexec-constructor/container (quote ("/gnu/store/z7qlqkb0qwnpcs5kbbf2z2js0k1xgkbv-libjami-20220726.1515.da8d1da/libexec/jamid" "--persistent" "--debug")) #:mappings (list (file-system-mapping (source "/dev/log") (target source)) (file-system-mapping (source "/var/lib/jami") (target source) (writable? #t)) (file-system-mapping (source "/var/run/jami") (target source) (writable? #t)) (file-system-mapping (source "/gnu/store/mjmpb4k2g21p7hyx9zq57p9xymbl16ac-nss-certs-3.71/etc/ssl/certs") (target "/etc/ssl/certs"))) #:user "jami" #:group "jami" #:environment-variables (list (string-append "DBUS_SESSION_BUS_ADDRESS=" "unix:path=/var/run/jami/bus") "SSL_CERT_DIR=/etc/ssl/certs")))) (setenv "DBUS_SESSION_BUS_ADDRESS" "unix:path=/var/run/jami/bus") (with-retries 20 1 (jami-service-available?)) (when #t (let* ((jami-account-archives (map (cut string-append "/var/lib/jami/accounts/" <>) (scandir "/var/lib/jami/accounts/" (lambda (f) (not (member f (quote ("." "..")))))))) (usernames (map-in-order (cut add-account <>) jami-account-archives))) (define (archive-name->username archive) (list-ref usernames (list-index (lambda (f) (string-suffix? (basename archive) f)) jami-account-archives))) (for-each (lambda (archive allowed-contacts moderators account-details) (let ((username (archive-name->username archive))) (when (not (unspecified? allowed-contacts)) (set-account-details (quote (("DHT.PublicInCalls" . "false"))) username) (for-each (cut remove-contact <> username) (username->contacts username)) (for-each (cut add-contact <> username) allowed-contacts)) (when (not (unspecified? moderators)) (set-all-moderators #f username) (for-each (cut set-moderator <> #f username) (username->moderators username)) (for-each (cut set-moderator <> #t username) moderators)) (set-account-details account-details username))) (quote ("/gnu/store/14flr53fr0hs7mzfwn93kmyzrnb3fhjz-dummy-jami-account.gz")) (quote (*unspecified*)) (quote (*unspecified*)) (quote ((("Account.rendezVous" . "true") ("Account.peerDiscovery" . "false") ("Account.hostname" . "bootstrap.me;fallback.another.host") ("RingNS.uri" . "https://my.name.server"))))))) daemon-pid) --8<---------------cut here---------------end--------------->8--- Can you spot where the problem is? Attached is the extended test I've used to test. You generate a VM with: --8<---------------cut here---------------start------------->8--- ./pre-inst-env guix system vm --no-graphics \ -e '(@@ (gnu tests telephony) %jami-os-provisioning-partial) --8<---------------cut here---------------end--------------->8--- To test with a more hands-on approach. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-gnu-telephony-Add-a-Jami-test-for-a-partially-define.patch >From 4ccaa9109c67174d428512b16a5c1ee77e66f491 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Mon, 1 Aug 2022 00:49:07 -0400 Subject: [PATCH] gnu: telephony: Add a Jami test for a partially defined jami-account. * gnu/tests/telephony.scm (%dummy-jami-account-partial): New variable. (make-jami-os): Add a PARTIAL? argument and use it to select the jami-account variant to use. (%jami-os-provisioning-partial): New variable. (run-jami-test): Add a PARTIAL? argument, and use it to select operating system variant. Skip allowed-contacts and moderators test when PARTIAL? is true. (%test-jami-provisioning-partial): New test. --- gnu/tests/telephony.scm | 49 +++++++++++++++++++++++++++++++++-------- 1 file changed, 40 insertions(+), 9 deletions(-) diff --git a/gnu/tests/telephony.scm b/gnu/tests/telephony.scm index 16ee313f69..b505f26e8d 100644 --- a/gnu/tests/telephony.scm +++ b/gnu/tests/telephony.scm @@ -31,7 +31,8 @@ (define-module (gnu tests telephony) #:use-module (guix gexp) #:use-module (guix modules) #:export (%test-jami - %test-jami-provisioning)) + %test-jami-provisioning + %test-jami-provisioning-partial)) ;;; ;;; Jami daemon. @@ -67,7 +68,18 @@ (define %dummy-jami-account (jami-account "fallback.another.host")) (name-server-uri "https://my.name.server"))) -(define* (make-jami-os #:key provisioning?) +;;; Like %dummy-jami-account, but with allowed-contacts and moderators left +;;; unset (thus taking the value *unspecified*). +(define %dummy-jami-account-partial + (jami-account + (archive %dummy-jami-account-archive) + (rendezvous-point? #t) + (peer-discovery? #f) + (bootstrap-hostnames '("bootstrap.me" + "fallback.another.host")) + (name-server-uri "https://my.name.server"))) + +(define* (make-jami-os #:key provisioning? partial?) (operating-system (host-name "jami") (timezone "America/Montreal") @@ -87,7 +99,10 @@ (define* (make-jami-os #:key provisioning?) (if provisioning? (jami-configuration (debug? #t) - (accounts (list %dummy-jami-account))) + (accounts + (list (if partial? + %dummy-jami-account-partial + %dummy-jami-account)))) (jami-configuration (debug? #t)))) (service dbus-root-service-type) @@ -109,12 +124,18 @@ (define %jami-os (define %jami-os-provisioning (make-jami-os #:provisioning? #t)) -(define* (run-jami-test #:key provisioning?) - "Run tests in %JAMI-OS. When PROVISIONING? is true, test the -accounts provisioning feature of the service." +(define %jami-os-provisioning-partial + (make-jami-os #:provisioning? #t #:partial? #t)) + +(define* (run-jami-test #:key provisioning? partial?) + "Run tests in %JAMI-OS. When PROVISIONING? is true, test the accounts +provisioning feature of the service. When PARTIAL? is #t, some fields of the +jami account used as part of the jami configuration are left *unspecified*." (define os (marionette-operating-system (if provisioning? - %jami-os-provisioning + (if partial? + %jami-os-provisioning-partial + %jami-os-provisioning) %jami-os) #:imported-modules '((gnu services herd) (guix combinators)))) @@ -202,7 +223,7 @@ (define marionette "Account.username"))))))) marionette)) - (unless #$provisioning? (test-skip 1)) + (unless #$(and provisioning? (not partial?)) (test-skip 1)) (test-assert "jami accounts provisioning, allowed-contacts" (marionette-eval '(begin @@ -224,7 +245,7 @@ (define marionette (assert (lset= string-ci=? contacts '#$%allowed-contacts))))) marionette)) - (unless #$provisioning? (test-skip 1)) + (unless #$(and provisioning? (not partial?)) (test-skip 1)) (test-assert "jami accounts provisioning, moderators" (marionette-eval '(begin @@ -341,3 +362,13 @@ (define %test-jami-provisioning (name "jami-provisioning") (description "Provisioning test for the jami service.") (value (run-jami-test #:provisioning? #t)))) + +;;; Thi test verifies that values can be left unspecified +;;; without causing any issue (see: https://issues.guix.gnu.org/56799). +(define %test-jami-provisioning-partial + (system-test + (name "jami-provisioning-partial") + (description "Provisioning test for the jami service, when some of the +'maybe' fields aren't provided (such that their value end up being +*unspecified*.") + (value (run-jami-test #:provisioning? #t #:partial? #t)))) -- 2.36.1 --=-=-= Content-Type: text/plain Thanks, Maxim --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 06:00:37 2022 Received: (at 56799) by debbugs.gnu.org; 1 Aug 2022 10:00:37 +0000 Received: from localhost ([127.0.0.1]:39371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oISE1-0003Sb-23 for submit@debbugs.gnu.org; Mon, 01 Aug 2022 06:00:37 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:53604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oISDz-0003SQ-L3 for 56799@debbugs.gnu.org; Mon, 01 Aug 2022 06:00:36 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by andre.telenet-ops.be with bizsmtp id 2A0a2800w20ykKC01A0auK; Mon, 01 Aug 2022 12:00:35 +0200 Message-ID: <24c7abd8-dbb3-8aaf-a7f8-5baa33fce48b@telenet.be> Date: Mon, 1 Aug 2022 12:00:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Content-Language: en-US To: Maxim Cournoyer , 56799@debbugs.gnu.org References: <877d3y8hjj.fsf@gmail.com> <20220728044144.15693-1-maxim.cournoyer@gmail.com> <87mtco4kkw.fsf_-_@gmail.com> From: Maxime Devos In-Reply-To: <87mtco4kkw.fsf_-_@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8xstXg0FqcL0q57l3go6WWZB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1659348035; bh=Xd8wlUAvcow5vgyg+Z77X+9KalBWzUy1rSepusrPzG0=; h=Date:Subject:To:References:From:In-Reply-To; b=gGgoFgXMDT57wj/BO+XoDktouckQ21Wy+NGPpxvBYf2uHVFHR9J5CvccqHZZjQpc4 dtLkgI1utBj8xlI/V/RebyMe/UXURaq/LXHosUN/ahTb3o+dEJQJRZ6XZUlyGqOE0R E0JP2ykmsEZSIbBqgIlZieVlbHPTsvrQXXvSIe27G/JNUxRMTPrMtTMLSoTrM6hM2H HfjZ1aiWGUL3pjfAMVwk32l8IwhYM4CMi0wcV+oCph18zRnRrnHnMJUkJN2MOTCEFD PSPDWZcbqgjgVFfVXsCy0W9NjyXk4TrNNauZ67jt5a4KneZnKhZqViXrw65020XsNR XGQ7WFvJhnXPQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 56799 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.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8xstXg0FqcL0q57l3go6WWZB Content-Type: multipart/mixed; boundary="------------4Mp9y0FkKNsHaL0M7TuVz6vO"; protected-headers="v1" From: Maxime Devos To: Maxim Cournoyer , 56799@debbugs.gnu.org Message-ID: <24c7abd8-dbb3-8aaf-a7f8-5baa33fce48b@telenet.be> Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <877d3y8hjj.fsf@gmail.com> <20220728044144.15693-1-maxim.cournoyer@gmail.com> <87mtco4kkw.fsf_-_@gmail.com> In-Reply-To: <87mtco4kkw.fsf_-_@gmail.com> --------------4Mp9y0FkKNsHaL0M7TuVz6vO Content-Type: multipart/mixed; boundary="------------BRjPsENJWQoRVa3eB7myKB6t" --------------BRjPsENJWQoRVa3eB7myKB6t Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAwMS0wOC0yMDIyIDA3OjA4LCBNYXhpbSBDb3Vybm95ZXIgd3JvdGU6DQo+ICAgICAg ICAgKHF1b3RlDQo+ICAgICAgICAgICgiL2dudS9zdG9yZS8xNGZscjUzZnIwaHM3bXpmd245 M2tteXpybmIzZmhqei1kdW1teS1qYW1pLWFjY291bnQuZ3oiKSkNCj4gICAgICAgICAocXVv dGUNCj4gICAgICAgICAgKCp1bnNwZWNpZmllZCopKQ0KPiAgICAgICAgIChxdW90ZQ0KPiAg ICAgICAgICAoKnVuc3BlY2lmaWVkKikpDQoNClRoZXNlIGxpbmVzIGxvb2sgc3VzcGljaW91 cyB0byBtZSAtLSBzaG91bGQgdGhleSBoYXZlIGRvbmUgKGxpc3QgDQoqdW5zcGVjaWZpZWQq KSBpbnN0ZWFkIG9mICcoKnVuc3BlY2lmaWVkKik/DQoNClRoZSBmb3JtZXIgdXNlcyB0aGUg YWN0dWFsIHVuc3BlY2lmaWVkIG9iamVjdCwgdGhlIGxhdHRlciB1c2VzIHRoZSANCnN5bWJv bCAnKnVuc3BlY2lmaWVkKicgdGhhdCBtZXJlbHkgaGFwcGVucyB0byBiZSB0aGUgbmFtZSBv ZiBhIHZhcmlhYmxlIA0KdGhlIHVuc3BlY2lmaWVkIG9iamVjdCBpcyBib3VuZCB0by4NCg0K R3JlZXRpbmdzLA0KTWF4aW1lLg0KDQo= --------------BRjPsENJWQoRVa3eB7myKB6t Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------BRjPsENJWQoRVa3eB7myKB6t-- --------------4Mp9y0FkKNsHaL0M7TuVz6vO-- --------------8xstXg0FqcL0q57l3go6WWZB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYuekQgUDAAAAAAAKCRBJ4+4iGRcl7lFd AQCeIQ2SXyxkQnjME8T82YQ4puo3mo46fBhdGeGFtdSgrwEAxW+aJLzWBVhNLl+rcpyKrG+x7ZaC 9Wa0K0jgTbUmtA8= =bJJg -----END PGP SIGNATURE----- --------------8xstXg0FqcL0q57l3go6WWZB-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 08:46:56 2022 Received: (at 56799) by debbugs.gnu.org; 1 Aug 2022 12:46:56 +0000 Received: from localhost ([127.0.0.1]:39623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIUoy-0002EL-8y for submit@debbugs.gnu.org; Mon, 01 Aug 2022 08:46:56 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:35565) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIUow-0002E7-Nn for 56799@debbugs.gnu.org; Mon, 01 Aug 2022 08:46:55 -0400 Received: by mail-qt1-f170.google.com with SMTP id g24so7883791qtu.2 for <56799@debbugs.gnu.org>; Mon, 01 Aug 2022 05:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ygn7xP0d8aGdMNrKEtQk/CT2CictMArJOpCADADiX9M=; b=NrHQcWcK31rWzxccK0kI5pOB/ZKAXkKcQf96MvwAX2SclU56cDxjs6VO5s58V1o68W 0e/FWFxfB86Oze4VbzOQKUawdZ2VG27zBKftS6mZi59Ckk9fItvHhuLqC6rVXryMlxft PLxgsZ3MC3qgD/pS/K/o79crP3TWlJKsc2Vw2bW1t65k+Y3LwulLz98ywnEZfdwSKj38 j8qkmo6Lf4M92lwRCXh6Yxv1dLDG1l+5ty1fNEDk4KbDWAOVNzUt/+kfik4BcbSv9Pe7 ckXYChhtbhztLZbKNkKNaJAZv/A1U2E8POc0WmuFOuwLSUJZlPiQ/hx7MzWoyZVlmP3f DgOQ== 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:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ygn7xP0d8aGdMNrKEtQk/CT2CictMArJOpCADADiX9M=; b=zcQb3VRC8CyO4vyNgHnCm4YOREzdc1ir+pKP3IJw1IudDBkuqccBknR3JidUqplaKH 3+uhexRN1freJFBsKwWFwnXCgjTndZudGZCmRTCKmkxD+X/Qme9pKPi2AAyzee+N+CJH KnwCRENpuo2etfRWHjghsN6x28P16Q+aZyYrcizSfTUgxj6RWMCrYjZ+sb9+luu/Dbwu zbrxv2Nzmrlnh+rC0UfaNXLXPrKj7+f1etYdPrkbwk+xWWug4pV1SSWu7TVRtIyPZe2p vyynp7il7GyXMvc8xTal/Yfaec1bsJKQ0RnwPFD0NN1/UpLvshUlV6e2OgfknEPINtee iVqw== X-Gm-Message-State: AJIora9h+orLzeqmv/zkkMwwzbI6SHGbpnZS000HML6puZ+MaTRRNVlr kqbipgd3Kpjm955gmkHaGUPemd79ut8= X-Google-Smtp-Source: AGRyM1sduT0y7pLQJALVt9Etn8RoFA7wXzSPiDHOZXTlyRTTBFTyT28+Kpj3X/Z3WpyEqutpk9bheg== X-Received: by 2002:a05:622a:1013:b0:31f:7b0:885d with SMTP id d19-20020a05622a101300b0031f07b0885dmr14180982qte.178.1659358008842; Mon, 01 Aug 2022 05:46:48 -0700 (PDT) Received: from hurd (dsl-158-240.b2b2c.ca. [66.158.158.240]) by smtp.gmail.com with ESMTPSA id e4-20020ac84904000000b0031ee01443b4sm7026804qtq.74.2022.08.01.05.46.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 05:46:48 -0700 (PDT) From: Maxim Cournoyer To: Maxime Devos Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <877d3y8hjj.fsf@gmail.com> <20220728044144.15693-1-maxim.cournoyer@gmail.com> <87mtco4kkw.fsf_-_@gmail.com> <24c7abd8-dbb3-8aaf-a7f8-5baa33fce48b@telenet.be> Date: Mon, 01 Aug 2022 08:46:46 -0400 In-Reply-To: <24c7abd8-dbb3-8aaf-a7f8-5baa33fce48b@telenet.be> (Maxime Devos's message of "Mon, 1 Aug 2022 12:00:34 +0200") Message-ID: <87czdk3zd5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@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, Maxime Devos writes: > On 01-08-2022 07:08, Maxim Cournoyer wrote: >> (quote >> ("/gnu/store/14flr53fr0hs7mzfwn93kmyzrnb3fhjz-dummy-jami-account.gz")) >> (quote >> (*unspecified*)) >> (quote >> (*unspecified*)) > > These lines look suspicious to me -- should they have done (list > *unspecified*) instead of '(*unspecified*)? > > The former uses the actual unspecified object, the latter uses the > symbol '*unspecified*' that merely happens to be the name of a > variable the unspecified object is bound to. Indeed; '*unspecified ain't the same as *unspecified, and it isn't magically evaluated after being lowered in a G-exp: --8<---------------cut here---------------start------------->8--- (map unspecified? (quote (*unspecified* *unspecified* *unspecified* *unspecified* *unspecified*))) $1 = (#f #f #f #f #f) --8<---------------cut here---------------end--------------->8--- So in essence the idea to simply quote *unspecified* from patch v3 is flawed. v1 works though (using a symbol), so unless someone has a better idea right now I'm thinking that using 'unset instead of *unspecified* may be the simplest working solution. Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 09:44:20 2022 Received: (at 56799) by debbugs.gnu.org; 1 Aug 2022 13:44:20 +0000 Received: from localhost ([127.0.0.1]:39787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIViW-00064b-1T for submit@debbugs.gnu.org; Mon, 01 Aug 2022 09:44:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIViR-00064L-4j for 56799@debbugs.gnu.org; Mon, 01 Aug 2022 09:44:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIViL-0004pV-SA; Mon, 01 Aug 2022 09:44:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=dSJ0141E5kDFCnlNzE0t7DHpriljjm4Cs5gdeFOwBUE=; b=a9zMZNF5AbGZCh8ce3P5 WfFiCVefZirwZWtZgGCNo06v6Sz6+PQnEiAIwNNiUFYFHRxEgvGwMng4gsRqhYKtx4wHh6/erY6ID k7Vu/C2EaEZRy61Po8/TsjkXMTqTCJcFfm/wELXqoAkURchqBpmAmmgJtbHq+sZvxzC5sFfexhAXc ZPHAx72XV39dysS9vhdyJgw1q+keOPXIiIjrbtVb+RDmFkLiZnRPq4fG/mBziSV27ZU6A1CXhaFng cjYneyqTJBtGsp7XHd9D0jQdS52FwckcXh2UIOogV1bFuBcsp4lhg4KJt+8gdBugVj/rR3f44d3ip J6UJ9p+vPrHtOw==; Received: from [193.50.111.124] (port=59632 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIViL-0004Yg-Ei; Mon, 01 Aug 2022 09:44:09 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <877d3y8hjj.fsf@gmail.com> <20220728044144.15693-1-maxim.cournoyer@gmail.com> Date: Mon, 01 Aug 2022 15:44:06 +0200 In-Reply-To: <20220728044144.15693-1-maxim.cournoyer@gmail.com> (Maxim Cournoyer's message of "Thu, 28 Jul 2022 00:41:44 -0400") Message-ID: <877d3sxemx.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@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: -3.3 (---) Hi! Maxim Cournoyer skribis: > Fixes . > > * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encounterin= g it. I think we need to take a step back. Overall, I=E2=80=99m reluctant to modifying a core primitive like =E2=80=98gexp->sexp=E2=80=99 =E2=80=9Cjust= =E2=80=9D to address this higher-level problem that we have. > + (($ (? unspecified?)) > + (return '*unspecified*)) Incidentally, this is =E2=80=9Cunhygienic=E2=80=9D, meaning that it relies = on =E2=80=98*unspecified*=E2=80=99 being bound to what we want. For example, = if I do this: #~(let ((*unspecified* 'hi!)) #$*unspecified*) =E2=80=A6 I won=E2=80=99t get the desired output. Ludo=E2=80=99, who now goes back to the beginning of the thread. :-) From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 09:49:44 2022 Received: (at 56799) by debbugs.gnu.org; 1 Aug 2022 13:49:44 +0000 Received: from localhost ([127.0.0.1]:39807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIVnk-0006GZ-0e for submit@debbugs.gnu.org; Mon, 01 Aug 2022 09:49:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIVni-0006GK-TG for 56799@debbugs.gnu.org; Mon, 01 Aug 2022 09:49:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49968) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIVnd-0005kN-2a; Mon, 01 Aug 2022 09:49:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=2ekT+tTRENRxdGBSfhjt6g28WlZFWc2oPcP+lcokCTM=; b=erwOkQzSS8DbooHJ6ioE cr+Cpd3GBMdSKbf73tFtlfdi9Zbntwg43xiQuTc36Zz/NsjtaGZGUxsVnwBhKi7YBNaY20MIAoZz4 wkMK4Xvt+F7NwqLyZir4sEPMJe96f570Y2ZIRlLLDaC4rCLCgQFBFUwxjru8PJ0+1wOHNBjLs1jdJ JdhyHDrtP+0dTPVFjtmaajtwD9YYVPZ6KqaUXtRbxg+BKmexzz71wL3xf+VzhELzqT4mpkqV/MOIR 9EZ95QCWlxBNgXBi2bHZqxdx77jqMXSl1+DheNbU/eglnfLczQAefQ5XYj2PGoJNBtRFw7gQpJor8 tbTKY0wQQpqVsw==; Received: from [2001:660:6102:310:f6b5:dff0:8fea:f7c9] (port=48522 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIVnb-0005Bh-Pt; Mon, 01 Aug 2022 09:49:36 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> Date: Mon, 01 Aug 2022 15:49:32 +0200 In-Reply-To: <87o7xa8qxt.fsf@gmail.com> (Maxim Cournoyer's message of "Wed, 27 Jul 2022 12:23:58 -0400") Message-ID: <8735egxedv.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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! Maxim Cournoyer skribis: > Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the > define-configuration machinery in (gnu services configuration) uses > *unspecified* instead of 'disabled for an unspecified field value. As Attila wrote, the rationale as discussed in was to specifically use a =E2=80=9Cspec= ial=E2=80=9D value without a read syntax in lieu of a symbol like 'disabled. > While this is indeed an improvement in readability, it introduces an > extra complication: because this new value is not self-quoting, it > cannot be used as is in G-Exps, and values using it must be carefully > expanded outside the gexp context, which is error prone. Could you give a simple example of how this can happen? In my experience, one would use =E2=80=98define-maybe=E2=80=99 and appropri= ate field serializers such that *unspecified* never goes through. Previously you=E2=80=99d check for (eq? x 'disabled) and now you just check for (unspecified? x). Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 11:55:31 2022 Received: (at 56799) by debbugs.gnu.org; 1 Aug 2022 15:55:31 +0000 Received: from localhost ([127.0.0.1]:41448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIXlT-00043d-0P for submit@debbugs.gnu.org; Mon, 01 Aug 2022 11:55:31 -0400 Received: from mail-qt1-f173.google.com ([209.85.160.173]:34730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIXlQ-00043M-GG for 56799@debbugs.gnu.org; Mon, 01 Aug 2022 11:55:29 -0400 Received: by mail-qt1-f173.google.com with SMTP id e5so8344627qts.1 for <56799@debbugs.gnu.org>; Mon, 01 Aug 2022 08:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=NPZ9+oqujikTRdXikbmO5Lqun5CwdyWmuCoVQUQRSWo=; b=XInZfPEb1YuXWIqnLBqwCHgx2gmx4+XF3v5D3AGCYyrWE88nesYydzBW+0K83rq5+J TLemkEWJolOO5YK4QigjmMl6OouLAZIyG4XJjchZu4bmakydUTlNR9sZDshehl44pxVM 4B6IiFMv4pyEevsdPCsmDjCF25LI3aOr4iFBNHKwF59QpN8nAfRxTwbvfYJAyJhay73/ 8k/TpaTuno5Xw5lbwmzIHOXtPYtQAs+FF/OseLUct/fyqbXaklA8/mVnn495mKZKLQ0R wnNApM0FDSPsUiD0a/IzlZEDTm85uW//1A6cWmR0EAEINW6aWjrTYG5b0eHw5WpAqKkE zEfA== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=NPZ9+oqujikTRdXikbmO5Lqun5CwdyWmuCoVQUQRSWo=; b=dFZUNXSy9VTH/jsBgC6dMhyUxmdP6J6RCgvj+VQJKI5c4a/0LWB2dlgI4VpGm+86VC GISfxxEt5FmHcy7tWp4nkK1wx4tvyPglFqWQENHx2gMnFygNeQJCDD96+0JCAcOaonYu 831TE60N9HBVNqEAYdHYDvGHkZjG4FCnVRUE3p4f3a7oJy9KkC+wbyf5GGddCXs+tiUy Be2b74hIBxFxFANYxtWLgZH8Xpcqq8pi59MUIM+tA2xBi4HIJvop9b5kpDOM11yqNpCg 0cZR1hEohNe/CvodyssHp/HeZx1HGbPEAGPYgniRyCNxEc9uykDEXvqB49H6d/f0lrUI 1Fsg== X-Gm-Message-State: AJIora+AeoIB9RlkL8Rf6a4lZz9o7In4bFpddcWu8B3iGm5UCKkyAtGR l0pWpmhoPStTZsgRCa4mq0Y= X-Google-Smtp-Source: AGRyM1uiEeX8CG8ikWmR+PUFQVk3ez+8o/M5B79vAECVwlB98Er3TaMP+jcUjUGlqjZOkbo4So+Kpg== X-Received: by 2002:a05:622a:54a:b0:31f:3822:7009 with SMTP id m10-20020a05622a054a00b0031f38227009mr15014788qtx.478.1659369322837; Mon, 01 Aug 2022 08:55:22 -0700 (PDT) Received: from hurd (dsl-158-240.b2b2c.ca. [66.158.158.240]) by smtp.gmail.com with ESMTPSA id i21-20020a05620a405500b006b5f371a19esm9482546qko.111.2022.08.01.08.55.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 08:55:22 -0700 (PDT) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> Date: Mon, 01 Aug 2022 11:55:20 -0400 In-Reply-To: <8735egxedv.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Mon, 01 Aug 2022 15:49:32 +0200") Message-ID: <87les82c2f.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 Ludo, Ludovic Court=C3=A8s writes: > Hi! > > Maxim Cournoyer skribis: > >> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the >> define-configuration machinery in (gnu services configuration) uses >> *unspecified* instead of 'disabled for an unspecified field value. > > As Attila wrote, the rationale as discussed in > was to specifically use a =E2=80=9Csp= ecial=E2=80=9D > value without a read syntax in lieu of a symbol like 'disabled. > >> While this is indeed an improvement in readability, it introduces an >> extra complication: because this new value is not self-quoting, it >> cannot be used as is in G-Exps, and values using it must be carefully >> expanded outside the gexp context, which is error prone. > > Could you give a simple example of how this can happen? > > In my experience, one would use =E2=80=98define-maybe=E2=80=99 and approp= riate field > serializers such that *unspecified* never goes through. Previously > you=E2=80=99d check for (eq? x 'disabled) and now you just check for > (unspecified? x). Yes, I understand that. What changed is that previously you could have the configuration serialized and used on the service side, which is what using *unspecified* made impossible. Granted, few services outside of Jami probably made use of this, but it was nevertheless a useful property. Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 12:55:29 2022 Received: (at 56799-done) by debbugs.gnu.org; 1 Aug 2022 16:55:30 +0000 Received: from localhost ([127.0.0.1]:41507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIYhV-0005u0-GR for submit@debbugs.gnu.org; Mon, 01 Aug 2022 12:55:29 -0400 Received: from mail-qk1-f171.google.com ([209.85.222.171]:43945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIYhS-0005tm-TS for 56799-done@debbugs.gnu.org; Mon, 01 Aug 2022 12:55:28 -0400 Received: by mail-qk1-f171.google.com with SMTP id o21so8824897qkm.10 for <56799-done@debbugs.gnu.org>; Mon, 01 Aug 2022 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Cd/dNokSvI304DnT8HOfAIyBk2nGe89RPhSlV+HPxuU=; b=R/kSfZhYSMeG0HeTuU8QlPqAL1+pzt0v7tg7m0kIVvf2TwhOhau6dkxpUurQI/68wq xQrxnyuE3J1hZKgEKbdNAmSe+Bs8ioqbfralmkH09HgPskEgIvLJOqdc1SnWt2tuM6Vz r6c09kJ3qHILMxpWsjB9szR1xVGtEiWLIX4bczd4ky8BwdDEcBdgVifowkD1r+bHyzBG ddEvvBxTw+LQ5VwQNz1FVuvXHzKAGequsoW6GBUo/4/rgVSHqhkPIsU2bj7YoI+d0ZwY CyYE+luKpuMor5A0bV0d3gSDOI9KE+E+EadW6IMHxvKV0pvs964SxWWb5iWneacYfnQk qGnw== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Cd/dNokSvI304DnT8HOfAIyBk2nGe89RPhSlV+HPxuU=; b=SpZMXbAifsRegLknJt/UMfZAGoWM7edWHhRjeVZ0MHQ/IrvO3TiiaVCxJJ1QuqpK1T 6v7vOzRrtqJndI9u3N0sEOP+5v3mTNEziuzcFWUZMfOpjANxRvnKyU+NxzgBTNOucGr8 lYx+pjYaZupVns+M5ff/aeolrxI3sgXNzE8g9HNE9XdnhReXx2kiG25/foi2bOjFTr+4 czSQppxw+3dTHFH4pmhgL5gx81sfkbuZxEMe2j07omb2lbJWZ0D7/EnDSCkMk7DMHNB3 yTF/iI+RUhPRSRdgMxBbod5fzlNy8tjNlsT2/e07dwM9Fzu2E8Zyae3A4vgS8DHKT93k op7A== X-Gm-Message-State: AJIora9v6Nc87tJIblwL2/YNjD+mCfUdKPQFa1HlEFWiN9MwTTW/HAXU 3RuAP3OVDuXo3KheZEpU3CHqm+Y3AVhZ6w== X-Google-Smtp-Source: AGRyM1sSBtKmlUP9/ZakyKVhhX2iIJ3p07/F3e8h93VK5x8eFTsx5dIpr/1j6VEjcDuDIWNR9LgZag== X-Received: by 2002:ae9:efd8:0:b0:6b5:df92:dc3b with SMTP id d207-20020ae9efd8000000b006b5df92dc3bmr12591320qkg.510.1659372921264; Mon, 01 Aug 2022 09:55:21 -0700 (PDT) Received: from hurd (dsl-158-240.b2b2c.ca. [66.158.158.240]) by smtp.gmail.com with ESMTPSA id s5-20020a05620a254500b006b5c80e2b6asm8764046qko.12.2022.08.01.09.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 09:55:20 -0700 (PDT) From: Maxim Cournoyer To: Tobias Geerinckx-Rice Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87a68uqz9r@nckx> <87fsim8l17.fsf@gmail.com> <87wnbypepu@nckx> Date: Mon, 01 Aug 2022 12:55:19 -0400 In-Reply-To: <87wnbypepu@nckx> (Tobias Geerinckx-Rice's message of "Wed, 27 Jul 2022 20:45:19 +0200") Message-ID: <87czdj3nuw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799-done Cc: attila@lendvai.name, 56799-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 (-) Hi, Tobias Geerinckx-Rice writes: > Hi Maxim, > > Maxim Cournoyer =E5=86=99=E9=81=93=EF=BC=9A >> For some background reading, see [0]. > > Thanks for the well-thought-out reply, and sharing this interesting > link! > > Now, it's just the musings of one person, but now I think I do agree > with (what I think is) the underlying vision: to hush up *unspecified* > and sneakily replace it with true nothingness. OK, I can live with > that. :-) > >> I think the semantic of the language is that it is to be used as the >> lack of a return value from a procedure or syntax, e.g.: >> >> (unspecified? (if #f 'one-arm-if)) -> #t > > Well=E2=80=A6 in the above context I'd hesitate to even imply > =E2=80=98semantics=E2=80=99. It's like undefined behaviour in C. Ascribe= it meaning > at your peril. Otherwise, point taken. > >> Having 'unspecified?' even defined in Guile seems to go against that >> idea; perhaps because Wingo themselves seems to disagree in [0]. > > Agreed. *This* was one of my reasons for supporting (field > *unspecified*), so it's nice to have it validated, even if it is > rejected. > >> I'm also thinking 'unspecified being too close to *unspecified* is >> probably going to cause confusion down the line. Reverting to the >> originally used 'disabled may be the lesser evil. > > Ah, here I can concentrate all my previous disagreement: hell no :-) > > It is the worstest evil; literally anything is better than > (enable-foo? 'disabled) defaulting to #t. > > Bikeshed this all y'all want, but 'default or 'unset or 'whatever are > miles better. OK. The v2 and v3 idea ended up not working, among lesser issues :-). So I went with v1, renaming the default value to 'unset; see commit a2b89a3319dc1d621c546855f578acae5baaf6da. Thanks for the naming suggestions. I also added a 'jami-provisioning-partial' system test to ensure it doesn't regress again if we decide to revisit this. Thanks, Closing. Maxim From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 03:31:27 2022 Received: (at 56799) by debbugs.gnu.org; 2 Aug 2022 07:31:28 +0000 Received: from localhost ([127.0.0.1]:42162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oImND-00029j-Gn for submit@debbugs.gnu.org; Tue, 02 Aug 2022 03:31:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oImNB-00029H-Au for 56799@debbugs.gnu.org; Tue, 02 Aug 2022 03:31:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39984) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oImN4-0002We-A8; Tue, 02 Aug 2022 03:31:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=vR4wkYI3U0c9ARDdK7hveBQ5xBGZgIa4JXtYDY7rBak=; b=AV9GRcJ6jzjRlpWPzG2d KQv9C36PPieCe2ZWH0qAhd16dr8CgcEF1FOV5KvlMkQZLKfScGe4omrF44tkQsxmGcDPnx5I1vAbP Vrs0PIpkyekpQsSmRqYWO99a2Lc8i9UBCWYHiVIERy2PaegbtPzZpnHVa+bIKJ8Vfc1kWaukmxGBj ElCBUJBu4xGcLxQXYLvjzSuZ0pGkyzA/JXRLjz5Qr+N+sAa8XoLHBZ6lVcdf2+YtMtHGgq4181rq4 1ead/Tat0+HjNcsU6WNwRMd70+okKJpZaopOo4RujwigCUxOUeYb1eNi8ElLYrITD7QU7+Hi7clIE /EhYpk5Ji/y4IQ==; Received: from [193.50.110.235] (port=43288 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oImN3-0004cq-Ph; Tue, 02 Aug 2022 03:31:18 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> Date: Tue, 02 Aug 2022 09:31:14 +0200 In-Reply-To: <87les82c2f.fsf@gmail.com> (Maxim Cournoyer's message of "Mon, 01 Aug 2022 11:55:20 -0400") Message-ID: <87v8rbumnx.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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, Maxim Cournoyer skribis: > Ludovic Court=C3=A8s writes: > >> Hi! >> >> Maxim Cournoyer skribis: >> >>> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the >>> define-configuration machinery in (gnu services configuration) uses >>> *unspecified* instead of 'disabled for an unspecified field value. >> >> As Attila wrote, the rationale as discussed in >> was to specifically use a =E2=80=9Cs= pecial=E2=80=9D >> value without a read syntax in lieu of a symbol like 'disabled. >> >>> While this is indeed an improvement in readability, it introduces an >>> extra complication: because this new value is not self-quoting, it >>> cannot be used as is in G-Exps, and values using it must be carefully >>> expanded outside the gexp context, which is error prone. >> >> Could you give a simple example of how this can happen? >> >> In my experience, one would use =E2=80=98define-maybe=E2=80=99 and appro= priate field >> serializers such that *unspecified* never goes through. Previously >> you=E2=80=99d check for (eq? x 'disabled) and now you just check for >> (unspecified? x). > > Yes, I understand that. What changed is that previously you could have > the configuration serialized and used on the service side, which is what > using *unspecified* made impossible. Do you have an example? Even on the service side, I imagine one could check for =E2=80=98unspecified?=E2=80=99 just like one would check for 'dis= abled, no? > Granted, few services outside of Jami probably made use of this, but it > was nevertheless a useful property. I don=E2=80=99t know of any. Having spent time reviewing the original change that Attila proposed and then chiming in on this issue, I would have hoped for a longer discussion before enacting the change in a2b89a3319dc1d621c546855f578acae5baaf6da. In addition to these issues around the process, I think we should strive for more stability. One of the reasons it took time to review is that interface changes are a commitment. Now commit a2b89a3319dc1d621c546855f578acae5baaf6da introduces a second interface change for reasons that are unclear to me (if the conclusion had been to revert, I=E2=80=99d have favored an actual r= evert rather than introducing 'unset). How should we move forward? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 04:46:05 2022 Received: (at 56799) by debbugs.gnu.org; 2 Aug 2022 08:46:06 +0000 Received: from localhost ([127.0.0.1]:42280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oInXR-00048p-FF for submit@debbugs.gnu.org; Tue, 02 Aug 2022 04:46:05 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:38920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oInXM-000489-NJ for 56799@debbugs.gnu.org; Tue, 02 Aug 2022 04:46:04 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 4593C62F45; Tue, 2 Aug 2022 08:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1659429954; bh=wTCXwFv45rX2Z2sh8iff7s44yBAYIDt1ZhrHMCY4Agg=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=SUrBELhk3sBpZW5AOLkByet3Is1yhkb8UTdVuLU+UoIEr99B4/eXHHnsjGPvq7lTy kwPtcswMG7AZJNF7oJKultSP7ne4n9I3kvItYqMqulgE5zZousT5eIMm6c0XhU2A03 XlWpy99LAriCFUHCqeLS8MXcWAmuPYakKSU66Jb1FeAu4phqTFZkTxk5L6t2HOt9cX JtP8po93h0ZSAQw201N6I4plPmKHo62A72lINpk+KtqEGIHDfUdy8ZvER7O5nmY3pg 47Io8kzULaH7fGHynEIjKhpUHjGn09qDVj17CubK7jheFECXNejZTL2ToeijbIs6s8 /xkdKL+DlV6xg== X-Virus-Scanned: Debian amavisd-new at emo07-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo07-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXTvbZkJ6nXk; Tue, 2 Aug 2022 08:45:53 +0000 (UTC) Received: from localhost (m83-185-47-186.cust.tele2.se [83.185.47.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id B0CD562EF2; Tue, 2 Aug 2022 08:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1659429953; bh=wTCXwFv45rX2Z2sh8iff7s44yBAYIDt1ZhrHMCY4Agg=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=ieA0CJIACN2tjv19TymmTQInrfTa7cqBwH3pDSQYjrp2v7AdUhMLnm77vjQreN9is Le43FKGxgTJTMz87g4jzPDBmYtl71xsPxWNtxKQG4yKSs0M9g9ywGPMHEHi3JzEgm6 sgEF4Gw5Ha4MqMooBKRTf+eRLH8XY3kAZwpE9qnfRndjd2jonwznsCwsBttE+VKT4c iac1mZxsTpJnGyZIYzZoIz/UrQpSxm8i1g24Q8qZeyR6sKqZr4ak8Z5LKL2pfKrwwG C5u3MET7lKZ/vfpgmdSxazo8jw7ZnoCbkHmkeRkEUt2Kvlt1FDiY8YQ47SlzrnFkHX PTnqRvOLrGFqQ== From: bokr@bokr.com Date: Tue, 2 Aug 2022 10:45:30 +0200 To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: <20220802084530.GA5603@LionPure> References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87v8rbumnx.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name, Maxim Cournoyer 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, On +2022-08-02 09:31:14 +0200, Ludovic Courtès wrote: > Hi, > > Maxim Cournoyer skribis: > > > Ludovic Courtès writes: > > > >> Hi! > >> > >> Maxim Cournoyer skribis: > >> > >>> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the > >>> define-configuration machinery in (gnu services configuration) uses > >>> *unspecified* instead of 'disabled for an unspecified field value. > >> > >> As Attila wrote, the rationale as discussed in > >> was to specifically use a “special” > >> value without a read syntax in lieu of a symbol like 'disabled. > >> > >>> While this is indeed an improvement in readability, it introduces an > >>> extra complication: because this new value is not self-quoting, it > >>> cannot be used as is in G-Exps, and values using it must be carefully > >>> expanded outside the gexp context, which is error prone. > >> > >> Could you give a simple example of how this can happen? > >> > >> In my experience, one would use ‘define-maybe’ and appropriate field > >> serializers such that *unspecified* never goes through. Previously > >> you’d check for (eq? x 'disabled) and now you just check for > >> (unspecified? x). > > > > Yes, I understand that. What changed is that previously you could have > > the configuration serialized and used on the service side, which is what > > using *unspecified* made impossible. > > Do you have an example? Even on the service side, I imagine one could > check for ‘unspecified?’ just like one would check for 'disabled, no? > > > Granted, few services outside of Jami probably made use of this, but it > > was nevertheless a useful property. > > I don’t know of any. > > Having spent time reviewing the original change that Attila proposed and > then chiming in on this issue, I would have hoped for a longer > discussion before enacting the change in > a2b89a3319dc1d621c546855f578acae5baaf6da. > > In addition to these issues around the process, I think we should strive > for more stability. One of the reasons it took time to review > is that interface changes are a > commitment. Now commit a2b89a3319dc1d621c546855f578acae5baaf6da > introduces a second interface change for reasons that are unclear to me > (if the conclusion had been to revert, I’d have favored an actual revert > rather than introducing 'unset). > > How should we move forward? > My 2¢ : Maybe separate commmit churn more formally into a release candidate series like Linus does for linux kernel, and have a long term stable guix only get what is agreed with solid consensus? AND, importantly: where issues involve subtleties of abstract entities vs their concrete representations, make sure this is clearly documented in the commit rationale, e.g., maybe using denottional semantics[1] like r5rs ? [1]: :) > Thanks, > Ludo’. > -- Regards, Bengt Richter OT PS: Has Boot-to-guile been updated by anyone? Kudos for the original! :) A RISCV qemu image? :) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 11:06:27 2022 Received: (at 56799) by debbugs.gnu.org; 2 Aug 2022 15:06:28 +0000 Received: from localhost ([127.0.0.1]:44757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oItTX-0000jV-CY for submit@debbugs.gnu.org; Tue, 02 Aug 2022 11:06:27 -0400 Received: from mail-qk1-f182.google.com ([209.85.222.182]:44641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oItTV-0000jA-Fu for 56799@debbugs.gnu.org; Tue, 02 Aug 2022 11:06:26 -0400 Received: by mail-qk1-f182.google.com with SMTP id b25so10784029qka.11 for <56799@debbugs.gnu.org>; Tue, 02 Aug 2022 08:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=xmASlgGiiN0qWvjeMGLDi0Bd7i6AMMQCpCLJDf/6c+I=; b=ODxGj/uy6KJF9NIr2UZs+5CjM+zta38SKOPHdfzrtFiSprX7uqEBmZN+jMkcbmzsnr Bd4FS1Has2bmE3BC29Ychq/MO2dIU+/8hXKEHTPwiWgTq5Kf/PmvnVYdXR/9VjHRKiwn 80BPg52bn2eaqDQDFbo0fUU0HgCRiEzq2Q1S8UVQGCiuoe0K/vljHd1anBZMyuClY690 rKCeF1NIjE+aHanm+PwJ17JYqNi2ILtrru+XnRZZnnnlTsA5IHEfJfLpLiNGETbu4GfM I8Y8diCke/amkfPJ9OiBMVlcdw1K+BZnjIt6Sh9Y58ZRs7JjlVc2hiFDaGv+5yIDiRmj WE+Q== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=xmASlgGiiN0qWvjeMGLDi0Bd7i6AMMQCpCLJDf/6c+I=; b=i0AGiY4rgsLAErDDurxPIYvCCOS5epEt/lC4+tZFkz4M3cSZfNuul8q7svwB6S8ZtJ 5w4IgsIC3gXkHVfLKTs/+/V1yel19hx2ao52Q1pq7dvM8r44n7A7mAuHZwFrMiUcahzv ybh7SMmn6KcBjd0vL1wNN9Esf40LADfR9Dlgds08+QRsN9x4LObsD0zqSOV7fDjog/JV GjOCZplKTSLMEkP9gkFbfvwgUy0cY+AbYenmRjnLS7h+dVUKESkfg8WIrfW/etPf4Ygx vgbGRMjJTLNmKnuE3AXx+/6BBLqJjJ4KDIl5gd+3MYRF8JzkZuf9U8OlClLBGJMNwL6N omXw== X-Gm-Message-State: AJIora98YDSl5bzK3XGe5Xb852b2kaxnImqIZIKvBjy6/40uMbaACqWF Kl9Z8fgEMfdjnGFFSitG17I= X-Google-Smtp-Source: AGRyM1vlwMTTeN0u78prPjydMVoGcC5WBSzeIBdImBAjoOjcjcSR0tEz5eoZY/G103O00R37LpGElQ== X-Received: by 2002:a05:620a:2556:b0:6a7:9f07:602 with SMTP id s22-20020a05620a255600b006a79f070602mr15248858qko.207.1659452779816; Tue, 02 Aug 2022 08:06:19 -0700 (PDT) Received: from hurd (dsl-151-182.b2b2c.ca. [66.158.151.182]) by smtp.gmail.com with ESMTPSA id h6-20020ac846c6000000b0033b6f4895afsm641137qto.42.2022.08.02.08.06.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Aug 2022 08:06:19 -0700 (PDT) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> Date: Tue, 02 Aug 2022 11:06:17 -0400 In-Reply-To: <87v8rbumnx.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 02 Aug 2022 09:31:14 +0200") Message-ID: <87sfme1y8m.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 Ludovic, Ludovic Court=C3=A8s writes: [...] >> Granted, few services outside of Jami probably made use of this, but it >> was nevertheless a useful property. > > I don=E2=80=99t know of any. I think mostly because few services make use of define-configuration. While attempting to write a new VNC service, it quickly became a visible annoyance: --8<---------------cut here---------------start------------->8--- (define-configuration/no-serialization xvnc-configuration (xvnc (file-like tigervnc-server) "The package that provides the Xvnc binary.") (display-number (number 0) "The display number used by Xvnc. You should set this to a number not already used a Xorg server.") (geometry (string "1024x768") "The size of the desktop to be created.") (depth (color-depth 24) "The pixel depth in bits of the desktop to be created. Accepted values = are 16, 24 or 32.") (port maybe-port "The port on which to listen for connections from viewers. When left unspecified, it defaults to 5900 plus the display number.") (ipv4? (boolean #t) "Use IPv4 for incoming and outgoing connections.") (ipv6? (boolean #t) "Use IPv6 for incoming and outgoing connections.") (password-file maybe-string "The password file to use, if any. Refer to vncpasswd(1) to learn how to generate such a file.") (frame-rate (number 60) "The maximum number of updates per second sent to each client.") (security-types (security-types (list "None")) (format #f "The allowed security schemes to use for incoming connections. The default is \"None\", which is safe given that Xvnc is configured to authenticate the user via the display manager, and only for local connectio= ns. Accepted values are any of the following: ~s" %security-types)) (localhost? (boolean #t) "Only allow connections from the same machine. It is set to #true by default for security, which means SSH or another secure means should be used to expose the remote port.") (log-level (log-level 30) "The log level, a number between 0 and 100, 100 meaning most verbose output. The log messages are output to syslog.") (extra-options (strings '()) "This can be used to provide extra Xvnc options not exposed via this record.")) [...] (define (xvnc-shepherd-service config) "Return a for Xvnc with CONFIG." ;; XXX: Ensure all the *unspecified* values are handled outside of gexps,= as ;; they are not valid gexp input (they are not self-quoting/serializable). ;; This would otherwise cause problem during 'guix deploy'. (let* ((display-number (xvnc-configuration-display-number config)) (port (if (unspecified? (xvnc-configuration-port config)) #f (xvnc-configuration-port config))) (port* (or port (+ 5900 display-number))) (inaddr (if (xvnc-configuration-localhost? config) INADDR_LOOPBACK INADDR_ANY)) (in6addr (if (xvnc-configuration-localhost? config) IN6ADDR_LOOPBACK IN6ADDR_ANY)) (ipv4-socket (and (xvnc-configuration-ipv4? config) (make-socket-address AF_INET inaddr port*))) (ipv6-socket (and (xvnc-configuration-ipv6? config) (make-socket-address AF_INET6 in6addr port*)))) (shepherd-service (provision '(xvnc vncserver)) (documentation "Run the Xvnc server.") (requirement '(networking syslogd)) (start #~(make-inetd-constructor #$(xvnc-configuration->command-line-arguments config) `(,@(if #$ipv4-socket (list (endpoint #$ipv4-socket)) '()) ,@(if #$ipv6-socket (list (endpoint #$ipv6-socket)) '())))) (stop #~(make-inetd-destructor))))) --8<---------------cut here---------------end--------------->8--- As you can see, the *unspecified* values need to be carefully massaged out before starting to assemble the G-exp, as they aren't valid G-Exp inputs. > Having spent time reviewing the original change that Attila proposed and > then chiming in on this issue, I would have hoped for a longer > discussion before enacting the change in > a2b89a3319dc1d621c546855f578acae5baaf6da. OK. > In addition to these issues around the process, I think we should strive > for more stability. One of the reasons it took time to review > is that interface changes are a > commitment. Now commit a2b89a3319dc1d621c546855f578acae5baaf6da > introduces a second interface change for reasons that are unclear to me > (if the conclusion had been to revert, I=E2=80=99d have favored an actual= revert > rather than introducing 'unset). I like to think of *unspecified* or 'unset as an uninteresting implementation detail that shouldn't be part of the public API. It's an implementation detail of the 'maybe' types/predicates generator of the (gnu services configuration) machinery. Perhaps we could introduce a 'maybe-set?' predicate to check them, to avoid leaking the implementation detail (the 'unset symbol). Also, after reading more on the topic, it became clear to me that *unspecified* is not meant as a value to be actively used by programmers in Scheme; it seems it's rather a value meant to be returned when the behavior of a procedure is unspecified [0]. Why 'unspecified?' even exist in Guile I don't know, I suppose because of some disagreement on the matter, as hinted in the previous link. The reason I did not simply revert was because the change also introduced something useful in the same code change, which is to lift the requirement to specify a default value for maybe-* fields. > How should we move forward? Perhaps we can discuss any issues I may have missed that arise from the this change, or possible future directions that would improve things. Thanks, Maxim [0] https://scheme-reports.scheme-reports.narkive.com/QSQtJSAh/unspecified= -values From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 04 08:20:33 2022 Received: (at 56799) by debbugs.gnu.org; 4 Aug 2022 12:20:33 +0000 Received: from localhost ([127.0.0.1]:51517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJZq4-0007rF-Kn for submit@debbugs.gnu.org; Thu, 04 Aug 2022 08:20:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJZq2-0007qr-3f for 56799@debbugs.gnu.org; Thu, 04 Aug 2022 08:20:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJZpw-0000D6-If; Thu, 04 Aug 2022 08:20:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=ctJGBaqTGA7kszIgsr3wp+0jktUuRhB/51rNXucfpMA=; b=BPbVgmJ/M+rRQQmc3LV6 KAp4aJykNmAMJDWkydg8gXaq2HBpqVsCLq+mldzzQvikZh1eeJuf7vAU6G/wTF1cU/IEYLFvurHYF +z9pIUbNIQHL9ktN+HOIJvuSeZ6HyDLcaVVp0Sd8mVMSpKUQQlA812oL0q4N2lspltXKCyfZ4fwZi Y0Fi8taa5ZUV9DyXR7cy6Gw/GxKyuM0LxWnAbSSFuzeKyt52Op84p8AWyTnssUY5zhF3yGb9fGRfL ZiJOeOWvX3d8uRLhpBW0SDW1tsj47kja2pneyl/U6SC+Y03eVzwCrKtL5veuWLnYn7Xi3y0ytbvkZ xxTAjIdx4VAS5A==; Received: from [2001:660:6102:310:f6b5:dff0:8fea:f7c9] (port=46774 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJZpb-0003qu-7X; Thu, 04 Aug 2022 08:20:19 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Septidi 17 Thermidor an 230 de la =?utf-8?Q?R=C3=A9v?= =?utf-8?Q?olution=2C?= jour du Lin X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 04 Aug 2022 14:19:59 +0200 In-Reply-To: <87sfme1y8m.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 02 Aug 2022 11:06:17 -0400") Message-ID: <877d3omc9c.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 (---) Howdy, Maxim Cournoyer skribis: >>> Granted, few services outside of Jami probably made use of this, but it >>> was nevertheless a useful property. >> >> I don=E2=80=99t know of any. > > I think mostly because few services make use of define-configuration. > While attempting to write a new VNC service, it quickly became a visible > annoyance: > > (define-configuration/no-serialization xvnc-configuration [...] > (port > maybe-port > "The port on which to listen for connections from viewers. When left > unspecified, it defaults to 5900 plus the display number.") [...] > (define (xvnc-shepherd-service config) > "Return a for Xvnc with CONFIG." > ;; XXX: Ensure all the *unspecified* values are handled outside of gexp= s, as > ;; they are not valid gexp input (they are not self-quoting/serializabl= e). > ;; This would otherwise cause problem during 'guix deploy'. > (let* ((display-number (xvnc-configuration-display-number config)) > (port (if (unspecified? (xvnc-configuration-port config)) > #f > (xvnc-configuration-port config))) OK, I see. I guess most of the time, we just call =E2=80=98serialize-xyz-configuration=E2=80=99, which automatically handles = *unspecified* values. In this case, =E2=80=98port=E2=80=99 is treated specially and inst= ead passed as a command-line argument. Other ways to address that come to mind include: adding =E2=80=98port=E2=80= =99 to the config file instead of on the command line (if possible), or doing: (serialize-configuration config (find (lambda (field) (eq? (configuration-field-name field) 'port)) xvnc-configuration-fields)) That=E2=80=99s a mouthful but maybe it could be abstracted. It does sound = less convenient though. That said, whether it=E2=80=99s =E2=80=98unspecified?=E2=80=99 or something= else, you have to have a check in place, right? With the new interface it becomes: (if (eq? port 'unset) #f port) Or you can provide an actual default value (an integer in this case), but that=E2=80=99s possible whether or not *unspecified* is the default val= ue. WDYT? >> In addition to these issues around the process, I think we should strive >> for more stability. One of the reasons it took time to review >> is that interface changes are a >> commitment. Now commit a2b89a3319dc1d621c546855f578acae5baaf6da >> introduces a second interface change for reasons that are unclear to me >> (if the conclusion had been to revert, I=E2=80=99d have favored an actua= l revert >> rather than introducing 'unset). > > I like to think of *unspecified* or 'unset as an uninteresting > implementation detail that shouldn't be part of the public API. It is part of the API for people who write services (but it=E2=80=99s defin= itely an implementation detail for someone who just uses services). > It's an implementation detail of the 'maybe' types/predicates > generator of the (gnu services configuration) machinery. Perhaps we > could introduce a 'maybe-set?' predicate to check them, to avoid > leaking the implementation detail (the 'unset symbol). Also, after > reading more on the topic, it became clear to me that *unspecified* is > not meant as a value to be actively used by programmers in Scheme; it > seems it's rather a value meant to be returned when the behavior of a > procedure is unspecified [0]. Why 'unspecified?' even exist in Guile > I don't know, I suppose because of some disagreement on the matter, as > hinted in the previous link. Right, even cleaner would be to have a specific value for this, like: (define &default-value (list 'default)) ;or something w/o read syntax (define (default? x) (eq? x &default-value)) But IMO it=E2=80=99s OK. > The reason I did not simply revert was because the change also > introduced something useful in the same code change, which is to lift > the requirement to specify a default value for maybe-* fields. Right, that makes sense to me. >> How should we move forward? > > Perhaps we can discuss any issues I may have missed that arise from the > this change, or possible future directions that would improve things. With the xvnc example, I better understand the kind of situation where a field value might end up directly in a gexp, though I=E2=80=99m still uns= ure whether use of *unspecified* really makes things worse. At least, because it lacks a read syntax, the problem is caught early on; whereas with 'unset, you might end up stuffing 'unset in your config file without noticing. Thanks for taking the time to discuss! Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 07 18:44:34 2022 Received: (at 56799) by debbugs.gnu.org; 7 Aug 2022 22:44:34 +0000 Received: from localhost ([127.0.0.1]:38487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKp0c-0005uK-Ep for submit@debbugs.gnu.org; Sun, 07 Aug 2022 18:44:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKp0Z-0005u5-V4 for 56799@debbugs.gnu.org; Sun, 07 Aug 2022 18:44:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKp0T-0000oK-LK; Sun, 07 Aug 2022 18:44:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=usx2BKG0aJuVD7Tmef07FWEOdre5uCDPIbYKpSoFh5M=; b=q7SOxntD5AKjUNp011IA l6qZ4KBLudkJ2PcC4LqJSuCu4liq+ZCYECFl8i51hdGHNnDWolB83TbDGEFSDSaWvpp+VlNygaWvs 02MCU276ssno2BSX4TDw4V8Ark+idBsgZ6ztmBaZMDD15asGGVV8/wejojKmYLOFC3FHY3otJKSCw Ct/ueBFtNsXD5cAvHRJEUxNnKb5nwAfGRET57JXbSs9KPvsvWz6rBBu8grr6dSmkQIrF1oXnCWY8U TEKoTzPVGo0biSwpUhb7C/5KYEzifBdcIBehkUnqLej/HbExFfR4vmqI+xWuWI7TPjUomvYWeaLdc kNt2T6TKc5i8VA==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:52528 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKp0T-0002Ov-8l; Sun, 07 Aug 2022 18:44:25 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Date: Mon, 08 Aug 2022 00:44:21 +0200 In-Reply-To: <877d3omc9c.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Thu, 04 Aug 2022 14:19:59 +0200") Message-ID: <87y1vzad2y.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 (---) Hello, I just hit this while running =E2=80=98guix home reconfigure=E2=80=99 from f0ae9da3210cc6d87ca519545203daf9751f3465: home-config.scm:24:16: error: invalid value unset for field 'address-fami= ly' It=E2=80=99s an =E2=80=98openssh-host=E2=80=99 record: (openssh-host (name "xyz") (host-name "xyz.example.org") (user "ludo")) =E2=87=92 #< %location: #f name: "xyz" host-name: "xyz.example.org" a= ddress-family: # identity-file: # port: # user: "ludo" forward-x11?: #f forward-x11-trusted?: #f forward-agent?= : #f compression?: #f proxy-command: # host-key-algorithms: #<= unspecified> accepted-key-types: # extra-content: ""> We have a new bug to address. Ludo=E2=80=99. From unknown Thu Aug 14 20:51:47 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Sun, 07 Aug 2022 22:45:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 07 18:44:51 2022 Received: (at control) by debbugs.gnu.org; 7 Aug 2022 22:44:51 +0000 Received: from localhost ([127.0.0.1]:38495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKp0s-0005v6-Vj for submit@debbugs.gnu.org; Sun, 07 Aug 2022 18:44:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKp0s-0005ui-8j for control@debbugs.gnu.org; Sun, 07 Aug 2022 18:44:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKp0n-0000p5-1d for control@debbugs.gnu.org; Sun, 07 Aug 2022 18:44:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:From:To:Date:in-reply-to: references; bh=efKatVopnuFfPrTAeg220dJkuS+EyqXdUS/rbncfYmY=; b=hekN6Fxy1bWdUC Ti1YtRzCS8PCDwMJkBwJPFgzXzPyRmjdWLIvrC32zkOwcVnyEobbCFSr3GAetveIA2Y+XpCuhvlyS AjmxcHHrVWPKOQlXwMmLag0T5yza3XzGVswl6ckMgdCbS39lipOeW9BvnxwItUGMPYSOaT+d2JSqj ens8me11/Rmqu5/uVPDEM85JVbAV8iVzaf+nRrAfK80oWoxAt3T9XowYBpx+yqwuDczGyagre3Mnd si/aJ4pb0l4lOfIbkuCcOGuD8d+uy0UVZRb7xbh0qm8jKh+tMqUMybHymExQHh7v3U+U6fqITTRy4 uMbxuurlDhpaFxuW7cdA==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:51122 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKp0m-0002PK-Kc for control@debbugs.gnu.org; Sun, 07 Aug 2022 18:44:44 -0400 Date: Mon, 08 Aug 2022 00:44:42 +0200 Message-Id: <87v8r3ad2d.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #56799 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) severity 56799 important quit From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 08 18:27:56 2022 Received: (at 56799) by debbugs.gnu.org; 8 Aug 2022 22:27:56 +0000 Received: from localhost ([127.0.0.1]:42105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLBE4-00023V-9p for submit@debbugs.gnu.org; Mon, 08 Aug 2022 18:27:56 -0400 Received: from mail-4323.proton.ch ([185.70.43.23]:43951) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLBDx-000237-OL for 56799@debbugs.gnu.org; Mon, 08 Aug 2022 18:27:54 -0400 Date: Mon, 08 Aug 2022 22:27:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail; t=1659997662; x=1660256862; bh=aPyh9X4LlfcUISUIfc2HfLmDM6Tfjhrgx8/+ASvMTVs=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=VRz9pwjnyuQmj1zVu8qGqUxC+4rvVkYDJeEpvmE5gDV84KpJuh5eZBP5wo6VMCJFD KbVBEJu1Vbf3o0LpzTMKbqArNxSlslKhZ+GVTXNzKbXdAKABafnYIjuhZXG/C2dFaE NDiMvyr+48EZSfK5Oh9Fjz5MHIo9vuwbFJzLKKi+mS6U+WRQDhtUU8TeLmvgsbVYw7 2iF2qan7MnxfSq7AfmRMx7PXnZjTvWoBh6jePr5BjZTCFtYiJi8fXG+pp6jfqx4D7b BYe2oV2eCIMXYdhws4F+UAYwqy3I9TNvjNjWGwd8Spm/gmt0zCMpUzw8ZX6TXDKilM RL64rSLSXS99A== To: =?utf-8?Q?Ludovic_Court=C3=A8s?= From: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: In-Reply-To: <877d3omc9c.fsf@gnu.org> References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Maxim Cournoyer 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: , Reply-To: Attila Lendvai Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) i got back online... > That said, whether it=E2=80=99s =E2=80=98unspecified?=E2=80=99 or somethi= ng else, you have to > have a check in place, right? With the new interface it becomes: > > (if (eq? port 'unset) #f port) > > Or you can provide an actual default value (an integer in this case), > but that=E2=80=99s possible whether or not unspecified is the default val= ue. i agree. > With the xvnc example, I better understand the kind of situation where > a field value might end up directly in a gexp, though I=E2=80=99m still u= nsure > whether use of unspecified really makes things worse. At least, > because it lacks a read syntax, the problem is caught early on; whereas > with 'unset, you might end up stuffing 'unset in your config file > without noticing. i agree with this, too. also, seems like it didn't register in this discussion, so i press it once = again: if the default/unspecified value is a symbol (any symbol), then thos= e configuration fields, whose type is set to be of symbol, will not error w= hen they are left unspecified. (see the FIELD-SANITIZER: it simply does a (= IF (PRED VALUE) ...) check, which doesn't fail because 'UNSET satisfies SYM= BOL?). i should have added a unit test for this... i think moving back from *UNSPECIFIED* to using 'UNSET only has drawbacks. = and if it works (read: it doesn't error out while guix is deploying the con= fig), then it probably produces illegal config files by serializing the uns= pecified value into an "unset" string in the config files. i'm obviously not aware of the entire complexity here, othrwise there would= n't have remained a bug... but regardless of the actual API/value used, i d= on't see how any of this could work without the service code explicitly che= cking for the unspecified value for fields that have a maybe type (i.e. who= se type allows the value to be unspecified). i think using a symbol instead= of *unspecified* only pushes the appearance of the symptoms farther away b= oth in time and space (otherwise there should have been a trivial fix to th= is without changing *unspecified* back to 'unset). either way, if there was a failing test case that i could run locally, then= i would have been more than happy to fix it... now i'm only dismayed that = all my service code, and my entire channel got broken. seems like i went of= fline in the worst two weeks. sidenote: what srfi-189 does is basically introduce such a special value th= at we are trying to hone in on here (i.e. Nothing, which is implemented as = a record instance) in a standardized way, and also an API to deal with this= special value in various different contexts (i.e. it exports stuff like MA= YBE-IF, MAYBE-FOLD, MAYBE-AND, etc). https://srfi.schemers.org/srfi-189/srfi-189.html -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CAlthough teachers do care and do work very, very hard, the institu= tion is psychopathic-it has no conscience. It rings a bell and the young ma= n in the middle of writing a poem must close his notebook and move to a dif= ferent cell where he must memorize that humans and monkeys derive from a co= mmon ancestor.=E2=80=9D =09=E2=80=94 John Taylor Gatto (1935=E2=80=93), 'Dumbing Us Down: The Hidde= n Curriculum of Compulsory Education' (1992) From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 08 19:35:22 2022 Received: (at 56799) by debbugs.gnu.org; 8 Aug 2022 23:35:22 +0000 Received: from localhost ([127.0.0.1]:42135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLCHJ-0003vM-Sj for submit@debbugs.gnu.org; Mon, 08 Aug 2022 19:35:22 -0400 Received: from mail-4022.proton.ch ([185.70.40.22]:42385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLCHI-0003v6-83 for 56799@debbugs.gnu.org; Mon, 08 Aug 2022 19:35:21 -0400 Date: Mon, 08 Aug 2022 23:35:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail; t=1660001713; x=1660260913; bh=Bxk3r8A0+T7PNaucpDNLwe82ptqdkuYwQEif7iC+8ek=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=UQLLKb40nWIuD58kUZbG6BhrYRUzRsYMwPANqpGXIwyd+g1itKC0CTTNMNhh2XjG+ O0yxbqQ6aL5ZsCkVtUDLMWdmyYGeenMehRgL3XzscMMWrZwlwZMocvTSMIYPQmS/4p jvECK9rIk2rgAf4BL2+j3BewJBbNgu4AAV6PC37FD1xKezm2kJOV7O+VUYVknu30AQ UZL6qZarJ3X9AfQBkBq36UCOeFBeP/eL5qnr9Mhw9urG7kvdmHP14UXlyHWjPfqqu6 9v+hnkdo1AbDbQD+DiiK3NY9AVremu/9E2hYHWpu6ingNrXzW6JlkUN6DFoP0//Ifj 3lxQPwt4YxXWg== To: =?utf-8?Q?Ludovic_Court=C3=A8s?= From: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: In-Reply-To: References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Maxim Cournoyer 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: , Reply-To: Attila Lendvai Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > i'm obviously not aware of the entire complexity here, othrwise > there wouldn't have remained a bug... but regardless of the actual > API/value used, i don't see how any of this could work without the > service code explicitly checking for the unspecified value for > fields that have a maybe type (i.e. whose type allows the value to > be unspecified). i think using a symbol instead of unspecified only > pushes the appearance of the symptoms farther away both in time and > space (otherwise there should have been a trivial fix to this > without changing unspecified back to 'unset). sorry, i was wrong/slow here^. i think i finally understand what the original issue was that triggered the= rollback: the *UNSPECIFIED* value cannot get through the GExp serialize/deserialize o= peration between the host/builder (or how do we call it?) and Shepherd. the= checks in the service code that handle the unspecified field values only h= appen when Shepeherd is executing the deserialized GExp's. the fix i would propose is to smarten up GExp serialization to handle which= ever value we use as the marker, be it 1) *UNSPECIFIED*, or 2) Nothing from= srfi-189, or 3) a record instance that we define/instantiate ourselves. i don't recommend 3). we should rather use srfi-189 then, because it sandar= dizes widely known concepts. so, would you accept a patch that implements 1) or 2) ? 2) has non-trivial uncertainties/complexities in making srfi-189 available = in all the required contexts, and not introducing any bootstrap related iss= ues in the process. because of that i would recommend getting to 2) by firs= t implementing 1) and then working towards 2) -- if we want to use srfi-189= at all, that is. -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CWhat's done to children, they will do to society.=E2=80=9D =09=E2=80=94 Karl A. Menninger (http://psychohistory.com/) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 20:43:18 2022 Received: (at 56799) by debbugs.gnu.org; 10 Aug 2022 00:43:19 +0000 Received: from localhost ([127.0.0.1]:45530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLZoc-000863-Co for submit@debbugs.gnu.org; Tue, 09 Aug 2022 20:43:18 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:33526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLZoY-00085p-Uo for 56799@debbugs.gnu.org; Tue, 09 Aug 2022 20:43:17 -0400 Received: by mail-qt1-f170.google.com with SMTP id u12so10172614qtk.0 for <56799@debbugs.gnu.org>; Tue, 09 Aug 2022 17:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=i1Jtu1pT8fQ0K1Cq6BYBOacEbQfo1soeVG3Qb3HMpDk=; b=Wkuhk727is6jgKDON/k9l1+1bnoEb600qiy5jJ13C1LPh64EFaoRrGLhMjVibcEnM+ nvbbtG+txOfBawu5Kwn1Ikk9vX+H4yVOqdgFHpKnl5uge17pTH20ZUlUsXG35XOmCHGU J9s6TEVeHYQeNodzb/SdKApy6XXrOWNDjKjO1LFVXmpcR9E7iI+aUTXvCdOxeCg13JeZ llZfOOEyH30p3n17XbnN6RoEk7zQzi/V+7OpqgS8ExVyfqt4mJm28h8kLWZ8foxukC1L mEogJB/MiKtgOa5Dq2DuExoKXSbR6TQ/BvvalX5ssgMvPwrpWLkJKcZt7Q36+/HFw9HI 8nzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=i1Jtu1pT8fQ0K1Cq6BYBOacEbQfo1soeVG3Qb3HMpDk=; b=m/bQ9avRt0jHg2M+jLrSxJ6WeC2D4vAUrSCBkBCkL5CPk6UgLPWCR8dav3RZ5Rr/lC 2LI104xzMka0TOoxNjoeul9lAFi3R51/GtVt0yYienQrH6PIfV/bs2Pv6vTFE5SW8utG n7sMdIzSLwXK8fn+yYwPMrn7szAO+gtdajOWcLfYqrj79ErKtkwnPUCmdE1jTFZhXGYU BWgOf4H7ZE1Vtm9vSxOXsPaoWUXKZyu0ygCSJdg4h1dUSPD90eCdvJWNa1Jbi9wmM+ut T9XCC5jMlDLEtWXpEZV3fLdnmvz6lLj82XHHg/YSoLgIuw7ILChdQUw6+IAfhS9fvRgm 6Byg== X-Gm-Message-State: ACgBeo37DgTGsGamemNVU29bPcAKGrpsgZFtrvz/LtZ0t1I556HloGZJ IjwyfrmGEbJOIvOQFwPTmfg= X-Google-Smtp-Source: AA6agR5Q+LT7J4fAgwDlprHQ2s8klfSPpBx2MSWdXYcca4WSmNoSwOVsamQSVs/lfHJ16dXsrbpA+g== X-Received: by 2002:ac8:7e89:0:b0:31f:3155:e9d with SMTP id w9-20020ac87e89000000b0031f31550e9dmr22528373qtj.477.1660092189238; Tue, 09 Aug 2022 17:43:09 -0700 (PDT) Received: from hurd (dsl-10-135-11.b2b2c.ca. [72.10.135.11]) by smtp.gmail.com with ESMTPSA id k5-20020a05620a414500b006b93ef659c3sm8155659qko.39.2022.08.09.17.43.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Aug 2022 17:43:08 -0700 (PDT) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Date: Tue, 09 Aug 2022 20:43:06 -0400 In-Reply-To: <877d3omc9c.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Thu, 04 Aug 2022 14:19:59 +0200") Message-ID: <87bkstnd2d.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, attila@lendvai.name 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Ludovic Court=C3=A8s writes: > Howdy, > > Maxim Cournoyer skribis: [...] >> I think mostly because few services make use of define-configuration. >> While attempting to write a new VNC service, it quickly became a visible >> annoyance: >> >> (define-configuration/no-serialization xvnc-configuration > > [...] > >> (port >> maybe-port >> "The port on which to listen for connections from viewers. When left >> unspecified, it defaults to 5900 plus the display number.") > > [...] > >> (define (xvnc-shepherd-service config) >> "Return a for Xvnc with CONFIG." >> ;; XXX: Ensure all the *unspecified* values are handled outside of gex= ps, as >> ;; they are not valid gexp input (they are not self-quoting/serializab= le). >> ;; This would otherwise cause problem during 'guix deploy'. >> (let* ((display-number (xvnc-configuration-display-number config)) >> (port (if (unspecified? (xvnc-configuration-port config)) >> #f >> (xvnc-configuration-port config))) > > OK, I see. I guess most of the time, we just call > =E2=80=98serialize-xyz-configuration=E2=80=99, which automatically handle= s *unspecified* > values. In this case, =E2=80=98port=E2=80=99 is treated specially and in= stead passed as > a command-line argument. Yes, and that provides much welcome flexibility, as records are serializable (as vectors) so long as the values they contain also are. > Other ways to address that come to mind include: adding =E2=80=98port=E2= =80=99 to the > config file instead of on the command line (if possible), or doing: > > (serialize-configuration config > (find (lambda (field) > (eq? (configuration-field-name field) > 'port)) > xvnc-configuration-fields)) > > That=E2=80=99s a mouthful but maybe it could be abstracted. It does soun= d less > convenient though. Xvnc takes no config switch, and I agree the above is not intuitive/great. It also wouldn't fix the use case of places it is more convenient to have the maybe value expanded into the gexp and dealt with there, such as used in the jami-service-type and in my previous example making use of a inetd style service, where shepherd-side only bindings such as endpoint makes it convenient to place the ports logic inside the service gexp. > That said, whether it=E2=80=99s =E2=80=98unspecified?=E2=80=99 or somethi= ng else, you have to > have a check in place, right? With the new interface it becomes: > > (if (eq? port 'unset) #f port) > > Or you can provide an actual default value (an integer in this case), > but that=E2=80=99s possible whether or not *unspecified* is the default v= alue. To me, the main use of maybe values is to allow for the daemon to use its own default when no value is specified. A maybe value with a default value makes little sense to me, so we should move toward eliminating that style and support for it from define-configuration, in my opinion. Things would be a bit easier to reason with then. As a baby step toward making 'unset a properly hidden implementation detail, I'd suggest the attached patch, which adds a means to check if a value was set. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-services-configuration-Add-a-maybe-value-set-procedu.patch >From ac84f836a5a6c451465a879521a306b6fbcbed50 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Fri, 5 Aug 2022 15:03:55 -0400 Subject: [PATCH] services: configuration: Add a 'maybe-value-set?' procedure. * gnu/services/configuration.scm (maybe-value-set?): New procedure. * doc/guix.texi (Complex Configurations): Document it. Remove comment showing usage of 'maybe-string' with a default value, which doesn't make sense. --- doc/guix.texi | 7 ++++++- gnu/services/configuration.scm | 5 +++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/guix.texi b/doc/guix.texi index eb3a1a4eb5..ccdd01f321 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -38998,7 +38998,7 @@ to be a string, or left unspecified. (name ;; If set to a string, the `serialize-string' procedure will be used ;; to serialize the string. Otherwise this field is not serialized. - maybe-string ; equivalent to (maybe-string *unspecified*) + maybe-string "The name of this module.")) @end lisp @@ -39029,6 +39029,11 @@ whether its value is set or not. @end lisp @end deffn +@deffn (Scheme Procedure) maybe-value-set? @var{value} +Predicate to check whether a user explicitly specified the value of a +maybe field. +@end deffn + @deffn {Scheme Procedure} serialize-configuration @var{configuration} @ @var{fields} Return a G-expression that contains the values corresponding to the diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index 3007e8de35..b41b4d2e62 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -57,6 +57,7 @@ (define-module (gnu services configuration) serialize-configuration define-maybe define-maybe/no-serialization + maybe-value-set? generate-documentation configuration->documentation empty-serializer @@ -300,6 +301,10 @@ (define-configuration stem (field field-type+def (define (empty-serializer field-name val) "") (define serialize-package empty-serializer) +(define (maybe-value-set? value) + "Predicate to check whether a 'maybe' value was explicitly provided." + (not (eq? 'unset value))) + ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) (define (str x) (object->string x)) -- 2.36.1 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [...] > With the xvnc example, I better understand the kind of situation where > a field value might end up directly in a gexp, though I=E2=80=99m still u= nsure > whether use of *unspecified* really makes things worse. At least, > because it lacks a read syntax, the problem is caught early on; whereas > with 'unset, you might end up stuffing 'unset in your config file > without noticing. I've been experimenting a lot with define-configuration recently and it gives you little chance to shoot yourself in the foot; it knows maybe values are not to be serialized, and won't wrote such values to config files. Thanks, Maxim --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 22:17:38 2022 Received: (at 56799) by debbugs.gnu.org; 10 Aug 2022 02:17:39 +0000 Received: from localhost ([127.0.0.1]:45599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLbHu-0001zM-GC for submit@debbugs.gnu.org; Tue, 09 Aug 2022 22:17:38 -0400 Received: from mail-qt1-f174.google.com ([209.85.160.174]:40587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLbHr-0001z7-3c for 56799@debbugs.gnu.org; Tue, 09 Aug 2022 22:17:36 -0400 Received: by mail-qt1-f174.google.com with SMTP id w28so2041731qtc.7 for <56799@debbugs.gnu.org>; Tue, 09 Aug 2022 19:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=8ARWpQqi9vogCQu1nvbQW/vZ+w8h1/HM+SY94lT0wug=; b=Ix4/ekSgtqoTOI8ISAlSHX+kELute63ScS1jX+1QSfA8nSe+wqMv/lhkoWrE5WOlTP SrGifNDGe0E99WutGI4+qiI8xYrbq5uVmugPeZCQtCDrxwnpR01z31O2DCwKiCBKwEI9 H0FKKw6m0TlUalEB/Di18Fy90qzkupWbGW2L7d4FW2AEZrSi6kD0jq1oQSvGDhNoScmm E0zkj0ICeDdC3heJDwntBJE/2KllyHu7MebFcR89/bDZmnvKNW6t7SpYeJRV6xmXfpWA YfkxS2H+qfBgiyD6BGB4wTOmDjLJBMnCh55poR7awRDgpq7dRLwk2ddpNBb3lqa2k7QM GbZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=8ARWpQqi9vogCQu1nvbQW/vZ+w8h1/HM+SY94lT0wug=; b=hZroI1aJnXGMdTs8O7yASLn2rI8T60qm4/Dd5DrL6gkhjk6xLi40xWq+b6DQtYDgU0 LFowiuV4ZeqhjiWJc/V8XN7MPAxh25W1LX39yr47yIR7yY8YQvCHwxmXPDvuJTXwER/k wHCjwwMSDOnDdBxgo6fvrJ1F7fMIhskUmXzwSdslDJBvBdJwx+TDRPJooT65UIFyzoqT 0EoMOAIVOCkinhPHe8CvP1QmPTzn5NSWHQmAHkr5e5cKoii3yyeTPB/Z7Tlw890i9+L1 82cBW7mQIEJPYtM/g5ia1HPmjaexTztfZzPDpDdirNjEExXIg1q5WvGyYAYr5sOO4wvl sKtA== X-Gm-Message-State: ACgBeo2YJixAigV1MET5jXie57JHJuWWFy5K6hwos1ZuGqFwCa4La8U8 M5Mb2y8H7IzbCaChSUhIYgqTk6SFUXA= X-Google-Smtp-Source: AA6agR6RZU4tBsvKwojR0E5hRpr3C/0jqeuc3fFafWJi7tlr9o4ENUMZ+PkDN1tBiX4eTglVRNxZww== X-Received: by 2002:a05:622a:490:b0:339:aea:70a5 with SMTP id p16-20020a05622a049000b003390aea70a5mr22466671qtx.351.1660097849288; Tue, 09 Aug 2022 19:17:29 -0700 (PDT) Received: from hurd (dsl-10-135-11.b2b2c.ca. [72.10.135.11]) by smtp.gmail.com with ESMTPSA id u11-20020a05620a0c4b00b006b60c965024sm12599859qki.113.2022.08.09.19.17.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Aug 2022 19:17:28 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Date: Tue, 09 Aug 2022 22:17:27 -0400 In-Reply-To: (Attila Lendvai's message of "Mon, 08 Aug 2022 23:35:03 +0000") Message-ID: <87k07gn8p4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= 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 Attila, Attila Lendvai writes: >> i'm obviously not aware of the entire complexity here, othrwise >> there wouldn't have remained a bug... but regardless of the actual >> API/value used, i don't see how any of this could work without the >> service code explicitly checking for the unspecified value for >> fields that have a maybe type (i.e. whose type allows the value to >> be unspecified). i think using a symbol instead of unspecified only >> pushes the appearance of the symptoms farther away both in time and >> space (otherwise there should have been a trivial fix to this >> without changing unspecified back to 'unset). > > > sorry, i was wrong/slow here^. > > i think i finally understand what the original issue was that triggered the rollback: > > the *UNSPECIFIED* value cannot get through the GExp > serialize/deserialize operation between the host/builder (or how do we > call it?) and Shepherd. the checks in the service code that handle the > unspecified field values only happen when Shepeherd is executing the > deserialized GExp's. That's the issue, yes! the *unspecified* value cannot cross the host/build border, which forces someone to pre-compute all things before serialization happens, which is inconvenient at best in some scenarios I hinted at (a recent one is defining inetd-style services, which endpoints need to be computed on the target (inside the service gexp)). > the fix i would propose is to smarten up GExp serialization to handle > whichever value we use as the marker, be it 1) *UNSPECIFIED*, or 2) > Nothing from srfi-189, or 3) a record instance that we > define/instantiate ourselves. That's what I first attempted, without success. That *unspecified* expands to some random object on every usage seems meant to discourage its usage as a specific value (its name, too!) > i don't recommend 3). we should rather use srfi-189 then, because it > sandardizes widely known concepts srfi-189 sounds fancy, but how would it be better than the 'unset symbol? Could you please restate the problems faced when using a symbol? Would it be lowerable into Gexp, unlike *unspecified*? To me, in Guile this means having a readily implemented reader syntax. > so, would you accept a patch that implements 1) or 2) ? As I mentioned earlier, the specific value used for a maybe value is an implementation detail, or should be made one, in my opinion. So it doesn't matter to me, as long as it makes writing services convenient and passes all the tests (I recently augmented the jami-service-type test which such a case to avoid any regressions). Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 23:26:39 2022 Received: (at 56799) by debbugs.gnu.org; 10 Aug 2022 03:26:39 +0000 Received: from localhost ([127.0.0.1]:45708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLcMg-0005v7-NM for submit@debbugs.gnu.org; Tue, 09 Aug 2022 23:26:39 -0400 Received: from mail-qv1-f44.google.com ([209.85.219.44]:42720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLcMd-0005us-6X for 56799@debbugs.gnu.org; Tue, 09 Aug 2022 23:26:36 -0400 Received: by mail-qv1-f44.google.com with SMTP id ct13so10070580qvb.9 for <56799@debbugs.gnu.org>; Tue, 09 Aug 2022 20:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=iYE79tqWJv9Q6TB5Mq5C7e/gamV80EpGXZx57cEkF3M=; b=e6eHGbunhfIGPZWr+U5RSBBk2K/vBHfoq+Y1na+QrtUyMSE9yJgulSS0+NfeeeyZdx fXeYNUEI87eikRvQxzYXB4FXmptJDX7B6NDWwbfTN31wEM1hS6vu3352KaHAwIoGVScP ZePEy+m2qOmybALu1wfI1yD3OjmXbnyzvUZ4uOyeuIc9XlYT/BQG9SvpYtyud3EOhkOy 5JZcIv5pswwmywXUYyD5hhKgLv+0Hlo8R4hN9V08ej4rCqj3MTcMRJqBP8oVEGeWX2nH rnZlMaSq3RHJz/0sPpCsp0NoyokoXuJrFCh/NXrxCR/+i0CFJ0xTmBDN/Uf6u/oNd+wx nZEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=iYE79tqWJv9Q6TB5Mq5C7e/gamV80EpGXZx57cEkF3M=; b=hACUiv6r+kaNJDmjPUyernsAg1LDZcbC5HWPCnFHDzQ3PzLJ/UZ1VmabBZfHSUuUNP 3v6ASQSD/of7M3YFjChKy/k+Zs9KF0oV+TNKGg6bhl15+wd72Qe4Gyb5fVkE1dhzPmZn QUosq172j7i5sFO4+s8LQtTKS9U/SEEmq+zPQte/CumMymD33JNyBrzuopzsrEXq30AA 8IalWVlN9/7/geKPUaBFSMwxbakRNGH/fRQGbmjYRleh345YO85wXsykkR9x0m4+2BuA eZEet8xlhPydKECPVtF3nYGRtibgPe727omAZNgomi+52Jl/J9bSj+lSmmGiKabTzxpw n/GA== X-Gm-Message-State: ACgBeo3+h0gpSIJ7FK5lhs/qZPWjwp9Eg6x4j7fwVJr4IM6NiYe7AvJ2 R6M5TNA2VsYkJbfjza87ePKO4Zlwh98= X-Google-Smtp-Source: AA6agR6WMp583SCp+pZgQMX1HLz+4SXNPtjwEE/oaseaJ/uz4Qr2Ajr1sV1vOlDfweF8fdASYyXkvQ== X-Received: by 2002:a05:6214:2342:b0:473:e142:f758 with SMTP id hu2-20020a056214234200b00473e142f758mr22664561qvb.83.1660101989294; Tue, 09 Aug 2022 20:26:29 -0700 (PDT) Received: from hurd (dsl-10-135-11.b2b2c.ca. [72.10.135.11]) by smtp.gmail.com with ESMTPSA id x8-20020a05620a258800b006b5e45ff82csm13127727qko.93.2022.08.09.20.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Aug 2022 20:26:28 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Date: Tue, 09 Aug 2022 23:26:27 -0400 In-Reply-To: (Attila Lendvai's message of "Mon, 08 Aug 2022 22:27:32 +0000") Message-ID: <878rnwn5i4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= 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 Attila, Attila Lendvai writes: [...] > also, seems like it didn't register in this discussion, so i press it > once again: if the default/unspecified value is a symbol (any symbol), > then those configuration fields, whose type is set to be of symbol, > will not error when they are left unspecified. (see the > FIELD-SANITIZER: it simply does a (IF (PRED VALUE) ...) check, which > doesn't fail because 'UNSET satisfies SYMBOL?). i should have added a > unit test for this... OK, I've reread this, and it is indeed a risk, that 'unset could leak in the case of a serializable configuration making use of a maybe-value field of type maybe-symbol. I've added the unit test suggested as 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected to fail'). Luckily no current service uses that. I think the tension between serializable vs non-serializable unspecified values comes from the two kind of usages of define-configuration: one is to generate config files, in which unspecified means "nothing", and shouldn't touch disk, while in the case it's used as a more general data type (define-configuration/no-serialization), there is value in being able to lower that data type on the build/target so that things can be lazily computed where needed, without loss of information. We should add one more unit test to exercise this last usage in action (currently only jami-service-type makes use of that, but I have an upcoming Xvnc service that benefits from that as well). Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 11 06:16:10 2022 Received: (at 56799) by debbugs.gnu.org; 11 Aug 2022 10:16:10 +0000 Received: from localhost ([127.0.0.1]:51726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oM5EX-0004tQ-Kv for submit@debbugs.gnu.org; Thu, 11 Aug 2022 06:16:10 -0400 Received: from mail-40136.proton.ch ([185.70.40.136]:56147) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oM5ES-0004sd-Vv for 56799@debbugs.gnu.org; Thu, 11 Aug 2022 06:16:08 -0400 Date: Thu, 11 Aug 2022 10:15:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail; t=1660212958; x=1660472158; bh=xDUvnKFAqXBLtJWu7JUdC34tAdoXiTynmQC55DIGSn8=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=Il6/BigE1Rjk9swvNCzqzHuubBhGNCmAZwRHMHw4ED+6XwO12JQjEhKTGyMMLeI1k QbYT14N/j8Hq5DogpXk3aj2xk4l9KUSxBNg/nUKa5lSVZt0XiFrR3GVknG2NWibz23 dV4bJpsimFB12FM4OKOOHz5DN6GaJTl7I7GBvIzs8fmiPeWQd3oHPfJcY+EHtYNobF EvGozzCTn0EUPUq9I2fHPcxFrLu5P8wBgCnXa8U/9zDLJg03P+bnJaNZ6EZHpJRgIa clxYYZCQZ1yD4YE7ySB3JQvr43Oz6r0HbvBGNrK7FX8SJlzPJ76uSHThYaTmcR4r6W SWIpv7B44wbZA== To: Maxim Cournoyer From: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: In-Reply-To: <878rnwn5i4.fsf@gmail.com> References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, =?utf-8?Q?Ludovic_Court=C3=A8s?= 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: , Reply-To: Attila Lendvai Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > OK, I've reread this, and it is indeed a risk, that 'unset could leak in > the case of a serializable configuration making use of a maybe-value > field of type maybe-symbol. I've added the unit test suggested as > 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected > to fail'). Luckily no current service uses that. thank you for that Maxim! and sorry for my initial, somewhat reactive, and emotionally driven respons= e earlier! maintaining a channel with complex services, and finally getting= the changes i needed merged into Guix proper was a source of frustration f= or me. i've looked at the current state of the code, and it looks good to me. the = only issues i have left are the following: 1) the (eq 'unset ...) scattered around the code; it should be hidden behin= d an explicit abstraction, but you yourself mentioned this already in an ea= rlier mail. i'd call it CONFIGURATION-FIELD-SET? (instead of MAYBE-SET?). i= t's longer, but we have completion in emacs, and it won't be used a gazilli= on times all around the code either. 2) the lack of an abstraction for the unset/unspecified value. whatever we = use as the marker should be hidden behind either an exported global variabl= e, or a function called UNSET-CONFIGURATION-FIELD! (or something alike). i = should have introduced these myself, and then your fix would have been as s= imple as replacing *UNSPECIFIED* with 'UNSET in the abstraction. 3) the SYMBOL? corner case that your test captures, but it's not a burning = issue for me (it doesn't affect the user facing API, once the above leakage= s are fixed). do you agree? if yes, will you implement it, or shall i prepare a patch? one more note: sometimes it's useful to have a field with a maybe type that= also has a default, together with the ability to explicitly unset this fie= ld. an example would be a port specification for a torrent client: it has some = default port, but it's possible to explicitly unset the port value to reque= st the allocation of a random port at startup. to better accommodate for this use case, 2) should probably be implemented = not as an UNSET-FOO! function, but as a global variable holding the unset v= alue marker. or maybe both? -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CThere is only one thing more harmful to society than an elected of= ficial forgetting the promises he made in order to get elected; that's when= he doesn't forget them.=E2=80=9D =09=E2=80=94 John McCarthy (1927=E2=80=932011), father of Lisp From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 02:32:12 2022 Received: (at 56799) by debbugs.gnu.org; 13 Aug 2022 06:32:12 +0000 Received: from localhost ([127.0.0.1]:59478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMkgu-0006C5-Aj for submit@debbugs.gnu.org; Sat, 13 Aug 2022 02:32:12 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:43537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMkgp-0006Bo-79 for 56799@debbugs.gnu.org; Sat, 13 Aug 2022 02:32:10 -0400 Received: by mail-qt1-f170.google.com with SMTP id a4so2261419qto.10 for <56799@debbugs.gnu.org>; Fri, 12 Aug 2022 23:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=V7BoSjtXC9VJeEROaD87AedI5Na4R1MgnbZ2VuYuajA=; b=c3l6/oEHhfkghJTLWfkEyoBimAMqhAw7zQWhmUFP+7YFGT7WSGiBZ78OAOOVH7AzE5 ZDo7FXexi4+p4qK68IAyvxyotiy3UtT8MHtLJdeKrzeHnLndo5wVVC79FenVafkB4Cwo BVgH2wIB7SsZaMW1fClly0S7VxUpxJgw9d0P615S3olEkvT7FquPdun+bqPBJa7l5mzO pAyH7Pzn9DrzRtCWkWD1zZJiFXh1O79S3ct/tNn4xApx+wI6U4UW3219qFOfIiBnHpFw XBZ+zqjr9qsF647WdJ/sXz9R0ZR5GDIyEyE2r6IYzbGDTcAg8OyUq6XWA0aoy1BZtAVM RbcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=V7BoSjtXC9VJeEROaD87AedI5Na4R1MgnbZ2VuYuajA=; b=a6opDCRzqrZdVVQf+5qVIxbdQrjj6v4Onanfmb9QO1VuLq1KP0la0w/mAQflkyqDig T9KYTbkN5kiShek3/4zauqxzGfVg7isssAqp8jFQJ7TWmn/awceWvBN+KfdglZg6BeOe c74Ny9/3m8Y4xFEKxT+Lv2f3pYKHH5O+t3QVnxyPlrWwOdpxIJDCrx+36FWlzMtEkdQQ W7AmjTMJWfXCjPiLuRW0qc3pOxesIH+AWyW10a4WNlOkxvJbmrgKt7Sj4d5m+GgI9T2U bSulRA2FVPXtKOuBAIcKU7hcH7y3oyP1pkbh99buz4yJlYCBA64CO8IiYvqL6S1kv1db 25hA== X-Gm-Message-State: ACgBeo1s3Q7qn7/P4D9NOMUrTV5SYJJ0zJgF5OOkOZQ5mWbCbFm0PygR l82Nh2GWSDoWkP/tdfqWGeklUbwJjwc= X-Google-Smtp-Source: AA6agR5gpPPCP7CBjK98PLSLy+1+4+rGI6iLF8V6DZfR9in3BgB6p2B24WQzJoAqwY5KwztleJi7vA== X-Received: by 2002:a05:622a:43:b0:343:7b9d:7f31 with SMTP id y3-20020a05622a004300b003437b9d7f31mr3888995qtw.521.1660372321161; Fri, 12 Aug 2022 23:32:01 -0700 (PDT) Received: from hurd (dsl-205-233-125-72.b2b2c.ca. [205.233.125.72]) by smtp.gmail.com with ESMTPSA id dt34-20020a05620a47a200b006b9815a05easm3648782qkb.26.2022.08.12.23.31.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 23:32:00 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> Date: Sat, 13 Aug 2022 02:31:59 -0400 In-Reply-To: (Attila Lendvai's message of "Thu, 11 Aug 2022 10:15:43 +0000") Message-ID: <87ilmwd57k.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= 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 Attila! Attila Lendvai writes: >> OK, I've reread this, and it is indeed a risk, that 'unset could leak in >> the case of a serializable configuration making use of a maybe-value >> field of type maybe-symbol. I've added the unit test suggested as >> 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected >> to fail'). Luckily no current service uses that. > > thank you for that Maxim! > > and sorry for my initial, somewhat reactive, and emotionally driven > response earlier! maintaining a channel with complex services, and > finally getting the changes i needed merged into Guix proper was a > source of frustration for me. No worries. We all get caught in emotions at times. It's not necessarily a bad thing, it's a sign we are invested and care. > i've looked at the current state of the code, and it looks good to me. the only issues i have left are the following: > > 1) the (eq 'unset ...) scattered around the code; it should be hidden > behind an explicit abstraction, but you yourself mentioned this > already in an earlier mail. i'd call it CONFIGURATION-FIELD-SET? > (instead of MAYBE-SET?). it's longer, but we have completion in emacs, > and it won't be used a gazillion times all around the code either. I had used maybe-value-set? because the maybe values are define via the 'define-maybe' syntax; they are not really part of 'define-configuration' and are sometimes used outside of it, such as in (guix home ssh). > 2) the lack of an abstraction for the unset/unspecified > value. whatever we use as the marker should be hidden behind either an > exported global variable, or a function called > UNSET-CONFIGURATION-FIELD! (or something alike). i should have > introduced these myself, and then your fix would have been as simple > as replacing *UNSPECIFIED* with 'UNSET in the abstraction. An exported variable seems simplest and perhaps less awkward to use, e.g. %unset or similar, although it's a bit ugly that we need to reify an unspecified value :-). > 3) the SYMBOL? corner case that your test captures, but it's not a burning issue for me (it doesn't affect the user facing API, once the above leakages are fixed). > > do you agree? if yes, will you implement it, or shall i prepare a patch? I sent a patch somewhere for the maybe-value-set?, see message-id <87bkstnd2d.fsf@gmail.com> up this thread. I'd be happy if you could prepare a patch for the other things mentionned here (an exported symbol). > one more note: sometimes it's useful to have a field with a maybe type > that also has a default, together with the ability to explicitly unset > this field. True. I'd prefer if this never was true for simplicity (a maybe field would not need to take a default value), but the reality is that we may want to set a sane default value while allowing the user to clear the field to have the software use its default behavior. > > an example would be a port specification for a torrent client: it has some default port, but it's possible to explicitly unset the port value to request the allocation of a random port at startup. > > to better accommodate for this use case, 2) should probably be > implemented not as an UNSET-FOO! function, but as a global variable > holding the unset value marker. or maybe both? I'd keep things simple with the exported unspecified value rather than both. A single, obvious way to do things is simpler. Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 12:47:20 2022 Received: (at 56799) by debbugs.gnu.org; 13 Aug 2022 16:47:20 +0000 Received: from localhost ([127.0.0.1]:34961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMuIC-00064U-EI for submit@debbugs.gnu.org; Sat, 13 Aug 2022 12:47:20 -0400 Received: from mail-4022.proton.ch ([185.70.40.22]:33707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMuI9-00064F-Q4 for 56799@debbugs.gnu.org; Sat, 13 Aug 2022 12:47:19 -0400 Date: Sat, 13 Aug 2022 16:47:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail; t=1660409231; x=1660668431; bh=HWAHzfh3ynLWCpqv7h9+ApkIC5S7Vx+MlUAX7Rjf8Yc=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=aJlbnJxXSgYm0b4egJTd7ali9lA/Q1RcRYj6JygrVgqX5iE/Yvuh1EiNM8pRcl4uA xIa2v2DuA56svhZmZHHNMx8bftA2NSs93YNx1f3geUJNw/15q3L/iEKWom3QlwnaMx +F+14FYmu+djKvZ48EOMS3s1tS4lsxVii8yOeuFxMjc0OoyQT35GLOBfT+GsRbws8t EwkX03Bpeu2x1QYFGGS1km5uDv3dhfnN9rs4PNc8LP42yP/+iORUsZbAkotqYzv6Cz dspMShIHFF4CTgXvkEKKU7M8CMtLAYPshwoBox66ZGzpMe/TNAfkxrOAL11gt4aSQx aAx2BPTCsGJaQ== To: Maxim Cournoyer From: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: In-Reply-To: <87ilmwd57k.fsf@gmail.com> References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> <87ilmwd57k.fsf@gmail.com> Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, =?utf-8?Q?Ludovic_Court=C3=A8s?= 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: , Reply-To: Attila Lendvai Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I had used maybe-value-set? because the maybe values are define via the > 'define-maybe' syntax; they are not really part of > 'define-configuration' and are sometimes used outside of it, such as in > (guix home ssh). oh! i wasn't aware of that. > An exported variable seems simplest and perhaps less awkward to use, > e.g. %unset or similar, although it's a bit ugly that we need to reify > an unspecified value :-). yeah, i started work on implementing an UNSET! function, and its API would be unnecessarily complex with a (type, field-name, instance) signature, and going through generic slot access in its implementation. > prepare a patch for the other things mentionned here (an exported > symbol). i started implementing your suggestions, including the replacement of the scattered usage of (eq? 'unset ...) pattern. what i found is that the code is not very readable using MAYBE-VALUE-SET?, or at least not for me. first, it negates the boolean logic everywhere in the current code (i.e. larger diff, and/or the use of (if (not ...) a b)). and an example wrt readability: (if (maybe-value-set? field-default) field-default (configuration-missing-default-value ...) a value is never set, only places can be set to some value. would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? then the boolean logic would remain the same, and the above example would look like: (if (unset-value? field-default) (configuration-missing-default-value ...) field-default) short of a response i'll continue working towards this in the following days and send a proposal eventually, but if you're very much unhappy about it, then let me know! -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- That, which is not falsifiable, can never be true. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 22:57:16 2022 Received: (at 56799) by debbugs.gnu.org; 14 Aug 2022 02:57:16 +0000 Received: from localhost ([127.0.0.1]:35489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN3oS-0006MZ-9S for submit@debbugs.gnu.org; Sat, 13 Aug 2022 22:57:16 -0400 Received: from mail-qv1-f47.google.com ([209.85.219.47]:44972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN3oO-0006MK-DB for 56799@debbugs.gnu.org; Sat, 13 Aug 2022 22:57:15 -0400 Received: by mail-qv1-f47.google.com with SMTP id mk9so3294019qvb.11 for <56799@debbugs.gnu.org>; Sat, 13 Aug 2022 19:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=lIiFCSz7ztpqlVQcDLMWhDR7J/KCzdePaZ1dwqOewGQ=; b=MBnZmHxngZ5DRaUTkNoulbkVfyXsJpkLzeqGg/X5F5q+Uhkj0dbKdqs2VaGI7eHbLT RHSEUTaxhg+Rrkzjh186kpaM+3Q7AjUlYOimOe4alLfYCMO9+mieTqGpP3zV4TDGS2uj nr3fvrmIQHJMz/OPmFCY0iAkZLJHfLyfzMGqkS34IvBShliGTjl8hbo8RF1qglit8kkB 4tE8CyCWJoeGPTk0sdha/cfEfy9LShxZ3SufBj+MVPiTgPYR+U+LwVuITzCuzLUazdHn ejex+wk1Ja0gzwWFjnbMo6NchFcLMutVslGdqLeMZ+eB73guOHwwqgm4f52FkOVux9E2 H7xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=lIiFCSz7ztpqlVQcDLMWhDR7J/KCzdePaZ1dwqOewGQ=; b=QPOrI+kOAILijJdXQrT+Rz/0HS5f9wjf4OJi905dBwReO4cCbqZHOZj+gGjemHIVOB P2MWW59uLnbSygQw6TqlGwXbdCb5Qi1ogck96uRJkfAZha7x3XFvhz6j7rsvV8VPcZlr GJr0DZ1eh1qXVNuHK69eGznjVDDyvERCYIS3pgxcr5gU63si9mqQU8CbFHzJ8O3ZjJMK mke+JIliu4/LtDxxDwHd4rMqXO3tjOb0vPdhqc9iL5zJsrvYUcVwkaU67zJ2fmO5fYoG m1ODH//f6V1GOrPyUV5MaVNAZMpL30S9XCsLny/6kjhxKjgo/MuhsBdZpeSlRyxZemLc a0Pw== X-Gm-Message-State: ACgBeo3ERZQKWpfBEasQ5TIy5Dls215NIqXOAcSMXCZzzLWyvmcjLiK2 rA49eR9soXEL2euvhOY181zBmsn9RuI= X-Google-Smtp-Source: AA6agR7mc17D21yiLO+THyuxNOEaI5ne3tBpnQyMm3xpnx7eqGGM0utlF95hkc8YX6r0ypxLyz9+lQ== X-Received: by 2002:a0c:9c48:0:b0:473:5e9e:741 with SMTP id w8-20020a0c9c48000000b004735e9e0741mr8949441qve.63.1660445826522; Sat, 13 Aug 2022 19:57:06 -0700 (PDT) Received: from hurd (dsl-205-233-125-72.b2b2c.ca. [205.233.125.72]) by smtp.gmail.com with ESMTPSA id b13-20020ac8678d000000b0034300e35487sm4873055qtp.54.2022.08.13.19.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Aug 2022 19:57:06 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> <87ilmwd57k.fsf@gmail.com> Date: Sat, 13 Aug 2022 22:57:05 -0400 In-Reply-To: (Attila Lendvai's message of "Sat, 13 Aug 2022 16:47:05 +0000") Message-ID: <87k07bbkhq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= 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 Attila, Attila Lendvai writes: [...] >> prepare a patch for the other things mentionned here (an exported >> symbol). Thanks! > i started implementing your suggestions, including the replacement of > the scattered usage of (eq? 'unset ...) pattern. what i found is that > the code is not very readable using MAYBE-VALUE-SET?, or at least not > for me. > > first, it negates the boolean logic everywhere in the current code > (i.e. larger diff, and/or the use of (if (not ...) a b)). > > and an example wrt readability: > > (if (maybe-value-set? field-default) > field-default > (configuration-missing-default-value ...) > > a value is never set, only places can be set to some value. It's not clear to me why you think the above is less readable; in the code I had to touch, the maybe-value-set? was more natural, as the cases I dealt with often tested for (not (eq? 'unset ...)), so reversing the logic allowed getting rid of the negation. See https://issues.guix.gnu.org/57168#13 for example. > > would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? unset-value? sounds like an action; so I'd name it 'maybe-value-unset?'; but as I wrote above I don't really see the benefit/like the idea. Thanks for working on it! Maxim From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 16 10:00:37 2022 Received: (at 56799) by debbugs.gnu.org; 16 Aug 2022 14:00:38 +0000 Received: from localhost ([127.0.0.1]:47887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNx7V-0004vw-JM for submit@debbugs.gnu.org; Tue, 16 Aug 2022 10:00:37 -0400 Received: from mail-4317.proton.ch ([185.70.43.17]:60339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNx7O-0004vC-JK for 56799@debbugs.gnu.org; Tue, 16 Aug 2022 10:00:32 -0400 Date: Tue, 16 Aug 2022 14:00:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail; t=1660658423; x=1660917623; bh=Kfv18lTwi1t9CLwju4pJkmixTElyLZy1y0vohp2qEkw=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=UVwMSf919+tFvxU+nA6vC8/79ibiyRvO1PVEh4ZAN02Ta73IQwUp25CSy8RmbkmH+ dplQpEKj84XrnKE2aAguz47QUxKnjMLdYQ+tp3t4K9BsK5JSRy749FmYnwcMqKrUUC KOaAUcbgXWX7Qhw2/tR4Vl4fZSnRUmy2Bhy5NYQjOPuxTgvIr1BMOlZ7MVcOwGQP1/ bhbrGf9Dm9tNelzT4WhcoW/VxDrBpRfmOtqW+Y6V7Ez2XG+m7+lpM0YKepKRt1uTaB Y6RTnWyO+Ryz8kh3Dk7mbdriAXThqSyftkZaZ3mKO4KjbIHd3X3CJiPAwZb1Eont+U fBmcjOwU5ZsWA== To: Maxim Cournoyer From: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Message-ID: In-Reply-To: <87k07bbkhq.fsf@gmail.com> References: <87o7xa8qxt.fsf@gmail.com> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> <87ilmwd57k.fsf@gmail.com> <87k07bbkhq.fsf@gmail.com> Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, =?utf-8?Q?Ludovic_Court=C3=A8s?= 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: , Reply-To: Attila Lendvai Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? > > > unset-value? sounds like an action; so I'd name it 'maybe-value-unset?'; > but as I wrote above I don't really see the benefit/like the idea. it's always funny when two non-native speakers (?) argue about english... := ) maybe we should invite one into the conversation? with that in mind: UNSET-VALUE? certainly doesn't look like an action to me= due to the question mark at the end. if we want to clearly disambiguate th= is, then we should insert 'is' somewhere, e.g. IS-UNSET-VALUE? which is a s= hort version of IS-IT-THE-UNSET-VALUE?, i.e. it is not a shorthand for IS-T= HIS-VALUE-UNSET?, because only places can be in the state of not set. does this clarify my perspective? it's not crucial, though. i can work my way through the changes without ren= aming this, but it'll be public API, so it's better to have something intui= tive and non-misleading published at the earliest possible iteration. -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CI sincerely believe that banking establishments are more dangerous= than standing armies, and that the principle of spending money to be paid = by posterity, under the name of funding, is but swindling futurity on a lar= ge scale.=E2=80=9D =09=E2=80=94 Thomas Jefferson (1743=E2=80=931826) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 17 09:16:29 2022 Received: (at 56799) by debbugs.gnu.org; 17 Aug 2022 13:16:29 +0000 Received: from localhost ([127.0.0.1]:49780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOIuL-0001TW-FJ for submit@debbugs.gnu.org; Wed, 17 Aug 2022 09:16:29 -0400 Received: from mail-qv1-f51.google.com ([209.85.219.51]:36582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOIuH-0001TE-Lv for 56799@debbugs.gnu.org; Wed, 17 Aug 2022 09:16:28 -0400 Received: by mail-qv1-f51.google.com with SMTP id y11so10021425qvn.3 for <56799@debbugs.gnu.org>; Wed, 17 Aug 2022 06:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=HL8fwJvXbHV9ViyJaeVxQfbpfJS4sKoUg0cyRANfvcY=; b=Y5g3sL5E+gmaTWPWlqjcKa2W6I3QZvKNs+UNW5thcwv5lCW+sUbSnj8gJBzcFlgoQX KFD8VvNOcanWhCrElyd2xUZG0X8xVFfXUVawhYb6E1mQrx6uvn1QWmZaaxeVrz3KEpmS 8Oo0Uy0L693R59akOO1rbSxXhv5WrBoAA6IUSeJp9W8+kohxxb1GHMnB+6F6RsagUQl8 PpBk+EHGHUqqoVbYdw93Yzn4o5SJ6MB87qLYbPzkNyovcNKm7R017Y7V9HF2O5Mwu5ez ruNcUWR4cmFl1zS141FUW7F1LWibVONi7hdGIpGfzJpGLo1T7gO6VF33MMpEMmJ+XN53 Errw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=HL8fwJvXbHV9ViyJaeVxQfbpfJS4sKoUg0cyRANfvcY=; b=i21K8NoN+RP2BosveACnH/rDD21qCSMM5bhVY9OyDxIgx46h1natdfhdSKfDOTtzNl 6BdVDYPd1yAP+Un5J+ntOuAb6hLOfpSxNSQhySmVZn95xLv35zsA/4Tz/YmRmtx158kg aK1eYaNl4V9PKsafvAuN6CQ+4fUVSqqCEP0qpc/luZmFM5UfZ6jWBVkRGyitjwPOcxy4 1Njkh1Dw8aIdDO4IQr5vH1tI7hZ2ycrDBlqAFyMdFfqb378CLlcdDyqTEDlrmrBLnWIS nVSs8PZzh55aKg99bHpbj3FMJLzyWyQZcuaEfLdKJanpKVJTbSdLB3Qd1IP8Is4Fd6zk 4VcQ== X-Gm-Message-State: ACgBeo3qifwo0AHeAS+kPzksXShM922BAyCF5HNx93DOaTT1bvrBBg1L UffYb004d8jCAhlcud449aVUMdi85yE= X-Google-Smtp-Source: AA6agR6xHBPOULh7Mu9SRdbbwOQUaM7CECriDhPvpgLYqiFa4BC2X0820d+mgOEs54Jfaqr4002utA== X-Received: by 2002:a0c:9046:0:b0:493:b227:e524 with SMTP id o64-20020a0c9046000000b00493b227e524mr9251638qvo.54.1660742179681; Wed, 17 Aug 2022 06:16:19 -0700 (PDT) Received: from hurd (dsl-10-134-72.b2b2c.ca. [72.10.134.72]) by smtp.gmail.com with ESMTPSA id w20-20020a05620a0e9400b006b928ba8989sm8347083qkm.23.2022.08.17.06.16.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 06:16:19 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <87o7xa8qxt.fsf@gmail.com> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> <87ilmwd57k.fsf@gmail.com> <87k07bbkhq.fsf@gmail.com> Date: Wed, 17 Aug 2022 09:16:17 -0400 In-Reply-To: (Attila Lendvai's message of "Tue, 16 Aug 2022 14:00:18 +0000") Message-ID: <87r11f9fj2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= 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 Attila, Attila Lendvai writes: >> > would you be fine if we renamed MAYBE-VALUE-SET? to UNSET-VALUE? >> >> >> unset-value? sounds like an action; so I'd name it 'maybe-value-unset?'; >> but as I wrote above I don't really see the benefit/like the idea. > > > it's always funny when two non-native speakers (?) argue about > english... :) maybe we should invite one into the conversation? Eh. I'm not a native English speaker either (although living in North America you can't really escape being exposed to it), but the naming issue here seems logical rather than subjective to me: unset can be both a verb or an adjective; by moving it after the noun, it communicates better that it acts as an adjective rather than as a verb. So instead of 'unset-value?', I'd use 'value-unset?', but since in this case we're dealing with a 'maybe' type defined with the 'define-maybe' macro, I'd keep 'maybe-value-unset?'. I hope this makes sense. Native English speakers are welcome to tip in, of course :-). Thanks, Maxim From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 17 12:00:07 2022 Received: (at 56799) by debbugs.gnu.org; 17 Aug 2022 16:00:07 +0000 Received: from localhost ([127.0.0.1]:52954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOLSh-0006X8-8e for submit@debbugs.gnu.org; Wed, 17 Aug 2022 12:00:07 -0400 Received: from knopi.disroot.org ([178.21.23.139]:50338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOLSe-0006Wi-42 for 56799@debbugs.gnu.org; Wed, 17 Aug 2022 12:00:06 -0400 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 7757B40083; Wed, 17 Aug 2022 18:00:02 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlUjEfUd0JmX; Wed, 17 Aug 2022 18:00:01 +0200 (CEST) Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1660752001; bh=QtlDsJsj9vrI9DJBy35EbPueTT9PRnN3Mvj8+k5/Oeo=; h=Date:To:Cc:Subject:From:References:In-Reply-To; b=kgNmos5P/bk6RieEVRU1yKo6N7a92pVsZOSqOQHpcfTA6Edeg7RjcwqZ7aDDHmIgI ebbbO2QY+mTl8phrCvEg2ZA8EQG7UilmS/h63hoX221rSrFhhEzENy4cRWx3jqpD2c bz+hmcG1WmRsi/v5ViPgU5y53VZzrp4m+nn0WK0IHZ2JBua1kspI9o98Wkx45M2K3j zo74FcPtyxIiXHk12z3yVvGk60sz2CwvaC1aM+Fseh6I1ZY0bdfHwtCNeGEdPnCCDo SSGLAd7mo8Xt46m4gdenSFb4GW5W+XaY9FHajHpKWFKVq0aky4bPi8R8Jq2n5P7182 b8Nj5rRqYng0A== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 17 Aug 2022 17:00:00 +0100 Message-Id: To: "Maxim Cournoyer" , "Attila Lendvai" Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic From: "(" References: <87o7xa8qxt.fsf@gmail.com> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> <87ilmwd57k.fsf@gmail.com> <87k07bbkhq.fsf@gmail.com> <87r11f9fj2.fsf@gmail.com> In-Reply-To: <87r11f9fj2.fsf@gmail.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799 Cc: 56799@debbugs.gnu.org, =?utf-8?q?Ludovic_Court=C3=A8s?= 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 (-) Hello Maxim, On Wed Aug 17, 2022 at 2:16 PM BST, Maxim Cournoyer wrote: > So instead of 'unset-value?', I'd use 'value-unset?', but since in this > case we're dealing with a 'maybe' type defined with the 'define-maybe' > macro, I'd keep 'maybe-value-unset?'. How about `unset?` or `maybe-unset?`? (I am a native English speaker, but to be honest I don't think that really matters much to this dicussion...) -- ( From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 24 08:41:12 2022 Received: (at 56799) by debbugs.gnu.org; 24 Aug 2022 12:41:12 +0000 Received: from localhost ([127.0.0.1]:45915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQph1-00081F-Tp for submit@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:12 -0400 Received: from mail-ej1-f44.google.com ([209.85.218.44]:39457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQpgw-00080e-LZ for 56799@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:10 -0400 Received: by mail-ej1-f44.google.com with SMTP id u15so24595930ejt.6 for <56799@debbugs.gnu.org>; Wed, 24 Aug 2022 05:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc; bh=eSDt8zmRXKS8Yhu9ydlpUZpveYmXH1nPJbzogUia+bk=; b=Qh2D2l6XknrJSnHgGqb52d3nSvTWhwMOJLKvyFzS2ppQJcVc71ctjLzc2NfDi5IHpX 7ICk5DobAwOKWEhnTE1eczYyAtuBYBS9bUaDPQR36p5rRR8BexZTC+kyA7eKDrT3OGuH bmy042VWZWlgSEUh2nYuQKuJfo9w3GbE9bvpMiNw09B6ycAAyNn5/itbvol4wWJ5vV/7 dvggD1q6DicKaWTMREAvtbpxH6kBy4UCbMroZHlNDK+39u3gpzlBihbzXi1//SVRuBRU w9gSgVCow26oX5TK/C4TPY8QDpgoFtLTf34FxOxATHPlbSpwjLHgVGXa+wo02bwBkkWV cOaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-message-state:from :to:cc; bh=eSDt8zmRXKS8Yhu9ydlpUZpveYmXH1nPJbzogUia+bk=; b=Hub+xP/E4BEUvuIZzqAHqbtIlqNgQhi1dGkeh2/o46FE/6BRIjbKTystY2aeaaYlUe FCAX0mKQjak7jqgffb/W1zSSJU5QIZo4QsSwM0uu83Q4tAIxouKEPXX+QHvLHdbGug13 QEiHi0IixW82un98hdFFVayr53eTQvSZvqMJVVcGotsK6zddSGYjwEEDFLG7R2UxvC3H 0tZ1WuvVW3HKpwiX9vWy/FAHZ6peiMZHCabPDidsWvVbv3sddEySTQAUsTzfzBm/x2zG J+MifXF7BBIwx/mHnEss0wPi+zb6GdBY5Xv+HjGSlF9XRZNrkDn6zHkLXKD8kZlkI06u vEiw== X-Gm-Message-State: ACgBeo2+xFt2PYy5RaVCPCBsFDYM2oT8pM3KlWT+d1DKHG9XpZ0eBodr z8954RBzu3ITEbm7CuKnH1JTNzC5In0= X-Google-Smtp-Source: AA6agR4OF0jVKs8l2aInux+4xxkTGcWtIBdDspf5cghsjxXDMTJu4Eo/YeL6QcWZwrQwNmVshrpQHw== X-Received: by 2002:a17:907:a426:b0:73d:9d53:b33 with SMTP id sg38-20020a170907a42600b0073d9d530b33mr2767354ejc.116.1661344860982; Wed, 24 Aug 2022 05:41:00 -0700 (PDT) Received: from localhost.localdomain ([2a02:ab88:7509:f780:ed82:a496:f55:e07b]) by smtp.gmail.com with ESMTPSA id f2-20020a17090631c200b006fee7b5dff2sm1114628ejf.143.2022.08.24.05.41.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 05:41:00 -0700 (PDT) From: Attila Lendvai To: 56799@debbugs.gnu.org Subject: [PATCH 2/5] services: configuration: Add %unset-value exported variable. Date: Wed, 24 Aug 2022 14:40:39 +0200 Message-Id: <20220824124042.10959-2-attila@lendvai.name> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220824124042.10959-1-attila@lendvai.name> References: <20220824124042.10959-1-attila@lendvai.name> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 56799 Cc: Attila Lendvai 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: -0.5 (/) * gnu/services/configuration.scm (%unset-value): New variable. (normalize-field-type+def): Use it. (maybe-value-unset?): Use it. --- gnu/services/configuration.scm | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index e2c4fe9998..a9426066b9 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -57,6 +57,7 @@ (define-module (gnu services configuration) serialize-configuration define-maybe define-maybe/no-serialization + %unset-value maybe-value-set? generate-documentation configuration->documentation @@ -172,10 +173,10 @@ (define (normalize-field-type+def s) (values #'(field-type def))) ((field-type) (identifier? #'field-type) - (values #'(field-type 'unset))) + (values #'(field-type %unset-value))) (field-type (identifier? #'field-type) - (values #'(field-type 'unset))))) + (values #'(field-type %unset-value))))) (define (define-configuration-helper serialize? serializer-prefix syn) (syntax-case syn () @@ -301,9 +302,18 @@ (define-configuration stem (field field-type+def (define (empty-serializer field-name val) "") (define serialize-package empty-serializer) +;; Ideally this should be an implementation detail, but we export it +;; to provide a simpler API that enables unsetting a configuration +;; field that has a maybe type, but also a default value. +;; +;; An example use-case would be something like a network application +;; that uses a default port, but the field can explicitly be unset to +;; request a random port at startup. +(define %unset-value 'unset) + (define (maybe-value-set? value) "Predicate to check whether a 'maybe' value was explicitly provided." - (not (eq? 'unset value))) + (not (eq? %unset-value value))) ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) -- 2.35.1 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 24 08:41:12 2022 Received: (at 56799) by debbugs.gnu.org; 24 Aug 2022 12:41:12 +0000 Received: from localhost ([127.0.0.1]:45917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQph2-00081H-7h for submit@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:12 -0400 Received: from mail-ej1-f52.google.com ([209.85.218.52]:43882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQph0-00080x-GP for 56799@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:10 -0400 Received: by mail-ej1-f52.google.com with SMTP id gb36so33239661ejc.10 for <56799@debbugs.gnu.org>; Wed, 24 Aug 2022 05:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc; bh=BXzFccNAioTNrtwtKF1NfWTp3i9MpLbsWl+Ya2NR4ks=; b=h65RWbrEx/xIhskx/YUfaFc22T44XAOHALL3N3w9vV8Wx5FZYdCZQt7PyCjFxkxKfu Ds8NKAMe2gYlVh8lb+xyW04XDBrommgVBsugYVaiT/qKvTa6DUaDWpj6PG835VodqA74 yIwB9ziLpu88uuqhB39rQFB9szT21gGRqQAo+RSFDPGaQ/5tWHAUJTU8wrpFCwXq3Ttq 1sAOKY2UlSulVb94lTP+XL097SJvbOvB/FLhaGAyvnQKPHJa+X8DbY+/QwEGV1wRYVTb DVLS9A97iwbDkDqGEtRlsE3FBj5KYcG9Eu+ZFj7nIUh9h5FhJ1Mj3UXpODX2+KxZsykX Lr4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-message-state:from :to:cc; bh=BXzFccNAioTNrtwtKF1NfWTp3i9MpLbsWl+Ya2NR4ks=; b=O74iOwaTdt3VCkaUZVhRH9TVjkAJQTsFr6RZ9SbTPnQs/dxCGHAgoHdUYjAURYocFc bzCDl+6L5kbb4Kyt9aT2xZFtRG89ea/cIeG1Mv9x47GlSF2uaBpmgWnMMNI3hApe//6g lydsml65hxrp37xsPFlAfyk2l2GFFXGv0D1dN19brfz8o83DQ9dSAkY1K0YcDxsiCwbk N6DLRW68gW6rIZxTnPbi8EfdYtJAIM70YmLP/2FQhRRTMyq4Lt2yluokkR0k113PK2XJ IrxJ2ao8aVECqxY31MVReHMYrfQSBNR8ByJoN4tE9sIfNWih02MwGMCUTdokOL2puRc/ pcHg== X-Gm-Message-State: ACgBeo31kH0G9G32JOorTv+4X4yCNBrMlrWZk7sT0eWZuAQVvyrxa6VR /fTz+XtdBApkrbbdjm6xc/BhKiPOnuI= X-Google-Smtp-Source: AA6agR5q4YkHKQxam7o6gtZHMXj+4ct1MWtBumA2rZ84/YXQORAlV424r+dNIdQuJ4/SRBXxWFAGeQ== X-Received: by 2002:a17:906:eecb:b0:73c:5c85:142b with SMTP id wu11-20020a170906eecb00b0073c5c85142bmr2800691ejb.433.1661344864873; Wed, 24 Aug 2022 05:41:04 -0700 (PDT) Received: from localhost.localdomain ([2a02:ab88:7509:f780:ed82:a496:f55:e07b]) by smtp.gmail.com with ESMTPSA id f2-20020a17090631c200b006fee7b5dff2sm1114628ejf.143.2022.08.24.05.41.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 05:41:04 -0700 (PDT) From: Attila Lendvai To: 56799@debbugs.gnu.org Subject: [PATCH 3/5] services: configuration: Add maybe-value exported procedure. Date: Wed, 24 Aug 2022 14:40:40 +0200 Message-Id: <20220824124042.10959-3-attila@lendvai.name> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220824124042.10959-1-attila@lendvai.name> References: <20220824124042.10959-1-attila@lendvai.name> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 56799 Cc: Attila Lendvai 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: -0.5 (/) * gnu/services/configuration.scm (maybe-value): New procedure. --- gnu/services/configuration.scm | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index a9426066b9..60965486a7 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -58,6 +58,7 @@ (define-module (gnu services configuration) define-maybe define-maybe/no-serialization %unset-value + maybe-value maybe-value-set? generate-documentation configuration->documentation @@ -315,6 +316,15 @@ (define (maybe-value-set? value) "Predicate to check whether a 'maybe' value was explicitly provided." (not (eq? %unset-value value))) +;; Ideally there should be a compiler macro for this predicate, that expands +;; to a conditional that only instantiates the default value when needed. +(define* (maybe-value value #:optional (default #f)) + "Returns VALUE, unless it is the unset value, in which case it returns +DEFAULT." + (if (maybe-value-set? value) + value + default)) + ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) (define (str x) (object->string x)) -- 2.35.1 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 24 08:41:19 2022 Received: (at 56799) by debbugs.gnu.org; 24 Aug 2022 12:41:19 +0000 Received: from localhost ([127.0.0.1]:45919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQph8-00081i-Mi for submit@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:19 -0400 Received: from mail-ej1-f43.google.com ([209.85.218.43]:36568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQpgs-00080Q-Ll for 56799@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:17 -0400 Received: by mail-ej1-f43.google.com with SMTP id d21so13936772eje.3 for <56799@debbugs.gnu.org>; Wed, 24 Aug 2022 05:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:sender:from:to:cc; bh=Sw1lpu+FGt7QUeK/SSB0xZaYrJwR3BCmYCIMm/Wuz6Q=; b=dcBC0hu/wn2KhddcxGxI9kXfnVf/Usner/U5m3FsbML+Ji9YPUfvzA6e8Oxb3tCUpN i0ixjcheI1uoO4L9Kl9RvhzCefjDRBaQ5RftogS8D6e8k/SVcswFZECkMtKWVN/PXTtB J3vMtXZ1Wmkdmk8yyimaj7Z7SmCxKZ6SpF66a+yOzIN4Krcdj0s8rSlZXqAuMLUJoZKa ZysN3+vYRd9oGqiADQpDmKcc1mAZ/wwGj05Ao9y///WpAODa0AzutC4LjbM1OR35IMSK qCLeYec+TomqqUQtjxHYnID2qNMl4+4LvBzbtcCWXyYWHGjoKlPvS/b/QRYY4yrM75YR GavA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:sender:x-gm-message-state:from:to:cc; bh=Sw1lpu+FGt7QUeK/SSB0xZaYrJwR3BCmYCIMm/Wuz6Q=; b=x+dSElg/ZBwmL1213IBrxX3TU12Jf3wwxJgI/94vv2X27EH77oWbiIHnzJBh4QAp5d F9Lss17VrmNRgUHpZS6+OFQt2GU65yDYzoNenIzXkle3ZNPDFvwu6Qv7ZkdH1FrlGHyG 0mfRsJzkuvj8wwha6MP+SqfJznrGoGn0Ko0MrO4hy1t7ieVGSp4jEzowIdjqcDX27/5g pD/d94ITvyC7J0x4FE7cu60fSvJzBAWnU5AIKZ0vs7JJivQcISJhWVh5gxqHRaMY2i25 nVkTMJWHkWq1wnTG/LL7Sx70zk01FwBGhRIGLgdY1jmnhN80wQQqM6E/rCYYU3ODDrlA XlsQ== X-Gm-Message-State: ACgBeo1ar64PI+gsrv/5KgcrGKex46TteqcU2QTlvzqAYBKNTolSNT4f BPt0eXgt2dsnvRbObPwXeQVVbH3fMxY= X-Google-Smtp-Source: AA6agR5uiZ6WXUmVjLGgrYtHh0zrTOIrt1ZuW4bNwUF5AJx50w36LQFmGoLMLUEWoK82FXUKgVq7XA== X-Received: by 2002:a17:906:58c8:b0:6fe:91d5:18d2 with SMTP id e8-20020a17090658c800b006fe91d518d2mr2908464ejs.190.1661344856799; Wed, 24 Aug 2022 05:40:56 -0700 (PDT) Received: from localhost.localdomain ([2a02:ab88:7509:f780:ed82:a496:f55:e07b]) by smtp.gmail.com with ESMTPSA id f2-20020a17090631c200b006fee7b5dff2sm1114628ejf.143.2022.08.24.05.40.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 05:40:55 -0700 (PDT) From: Attila Lendvai To: 56799@debbugs.gnu.org Subject: [PATCH 1/5] services: configuration: Add a 'maybe-value-set?' procedure. Date: Wed, 24 Aug 2022 14:40:38 +0200 Message-Id: <20220824124042.10959-1-attila@lendvai.name> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 56799 Cc: Attila Lendvai , Maxim Cournoyer 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: -0.5 (/) From: Maxim Cournoyer * gnu/services/configuration.scm (maybe-value-set?): New procedure. * doc/guix.texi (Complex Configurations): Document it. Remove comment showing usage of 'maybe-string' with a default value, which doesn't make sense. Co-authored-by: Attila Lendvai --- doc/guix.texi | 7 ++++++- gnu/services/configuration.scm | 15 ++++++++++----- 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index 86cfe7d49c..039df29ebc 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -38999,7 +38999,7 @@ to be a string, or left unspecified. (name ;; If set to a string, the `serialize-string' procedure will be used ;; to serialize the string. Otherwise this field is not serialized. - maybe-string ; equivalent to (maybe-string *unspecified*) + maybe-string "The name of this module.")) @end lisp @@ -39030,6 +39030,11 @@ whether its value is set or not. @end lisp @end deffn +@deffn (Scheme Procedure) maybe-value-set? @var{value} +Predicate to check whether a user explicitly specified the value of a +maybe field. +@end deffn + @deffn {Scheme Procedure} serialize-configuration @var{configuration} @ @var{fields} Return a G-expression that contains the values corresponding to the diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index 3007e8de35..e2c4fe9998 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -57,6 +57,7 @@ (define-module (gnu services configuration) serialize-configuration define-maybe define-maybe/no-serialization + maybe-value-set? generate-documentation configuration->documentation empty-serializer @@ -142,7 +143,8 @@ (define (define-maybe-helper serialize? prefix syn) (id #'stem #'serialize-maybe- #'stem)))) #`(begin (define (maybe-stem? val) - (or (eq? val 'unset) (stem? val))) + (or (not (maybe-value-set? val)) + (stem? val))) #,@(if serialize? (list #'(define (serialize-maybe-stem field-name val) (if (stem? val) @@ -260,11 +262,10 @@ (define #,(id #'stem #'stem #'-fields) (default-value-thunk (lambda () (display '#,(id #'stem #'% #'stem)) - (if (eq? (syntax->datum field-default) - 'unset) + (if (maybe-value-set? (syntax->datum field-default)) + field-default (configuration-missing-default-value - '#,(id #'stem #'% #'stem) 'field) - field-default))) + '#,(id #'stem #'% #'stem) 'field)))) (documentation doc)) ...)))))))) @@ -300,6 +301,10 @@ (define-configuration stem (field field-type+def (define (empty-serializer field-name val) "") (define serialize-package empty-serializer) +(define (maybe-value-set? value) + "Predicate to check whether a 'maybe' value was explicitly provided." + (not (eq? 'unset value))) + ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) (define (str x) (object->string x)) -- 2.35.1 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 24 08:41:24 2022 Received: (at 56799) by debbugs.gnu.org; 24 Aug 2022 12:41:24 +0000 Received: from localhost ([127.0.0.1]:45922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQphD-00081z-BA for submit@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:23 -0400 Received: from mail-ed1-f53.google.com ([209.85.208.53]:36568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQphA-00081Y-IU for 56799@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:21 -0400 Received: by mail-ed1-f53.google.com with SMTP id w10so9730410edc.3 for <56799@debbugs.gnu.org>; Wed, 24 Aug 2022 05:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc; bh=0Fwrp6nxrXLxGj0dPcOpp3eHE7TtqCEnW5Mdr8aBjEk=; b=YSfoAIV2gcCORWlLrpxoGAmkcsbk60WnbY9TUVI832v4dPuFFkC1lsmOQMaZkLsf6w GdAAinBVNN0H7VJw+0QKRuDUeGdVGRaj+7OPz32mejYIo0tK67hauIEO6xLiEmUy9XmC CCmDKtnsNovPFIWKbRpIXjJSIucsT4gphH8D8wnMyc/rU8SOxiwvMtLpickymJCBjuam PHF6R0jHgJCf0XU+sa6Spvv8sE6Vv3OBJ1+g4WA4ya+xqL1SuBIIUBRGQWWfXeYCYJsB AaFrqxM6Ac0TS99TCUu0o+rfqapvMh+tseGt/ij5uEy5d0RmL0jEbuRBQ/QBknP82muN Ifig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-message-state:from :to:cc; bh=0Fwrp6nxrXLxGj0dPcOpp3eHE7TtqCEnW5Mdr8aBjEk=; b=jpiP8kSv9nCK/3e+AM239JMzjYSDCMCJTkHAbPNqhhuYSUpZBveiKGkXaWI5t9c1z2 O0vxS1yyEKzPJa5VZaLJRJTHfxfoMQkigZhdmfxKTD10oRSZJVMuox2pnZ2iEV7vl1RJ UM0zyDWmqw/Gop3gqBiQezVRpIYb5zpUEN3/szIp4AArfnkHiaiOaKLiCItMYK47b9Gu TCLsjCtwcnJddNMadjNc1dyox1wHQ9YCJmIo14jUabSNbBMmLAXkkNb/V4wx+lc58rJH CUaq/Tfz3Ot/d+762F31u7lQnuopGdpoJO+OQZ1Nik+bCIANz8crNF64Eecd5GUCu0Iy PgQA== X-Gm-Message-State: ACgBeo0mM9NAro0yxYoloIRAqlobE6TNeg1IH3okNjAl1UITsyG6uUyH BtaG+vLGCAAwodinlN1gqOW0UBKGATY= X-Google-Smtp-Source: AA6agR7iiU0wjTMtC/szBiTiDXRrc99jRVeAx2p7alVy36tqn9zZxvXDjZtgGPjQA8KbdKs2c59O5Q== X-Received: by 2002:a05:6402:3681:b0:446:ba68:573f with SMTP id ej1-20020a056402368100b00446ba68573fmr7600090edb.137.1661344874639; Wed, 24 Aug 2022 05:41:14 -0700 (PDT) Received: from localhost.localdomain ([2a02:ab88:7509:f780:ed82:a496:f55:e07b]) by smtp.gmail.com with ESMTPSA id f2-20020a17090631c200b006fee7b5dff2sm1114628ejf.143.2022.08.24.05.41.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 05:41:14 -0700 (PDT) From: Attila Lendvai To: 56799@debbugs.gnu.org Subject: [PATCH 4/5] services: Use the new maybe/unset API. Date: Wed, 24 Aug 2022 14:40:41 +0200 Message-Id: <20220824124042.10959-4-attila@lendvai.name> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220824124042.10959-1-attila@lendvai.name> References: <20220824124042.10959-1-attila@lendvai.name> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 56799 Cc: Attila Lendvai 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: -0.5 (/) * gnu/home/services/ssh.scm (serialize-address-family): Use the public API of the maybe infrastructure. * gnu/services/file-sharing.scm (serialize-maybe-string): Use maybe-value. (serialize-maybe-file-object): Use maybe-value-set?. * gnu/services/getmail.scm (getmail-retriever-configuration): Don't use internals in unset field declarations. (getmail-destination-configuration): Ditto. * gnu/services/messaging.scm (raw-content?): Use maybe-value-set?. (prosody-configuration): Use %unset-value. * gnu/services/telephony.scm (jami-shepherd-services): Use maybe-value-set?. (archive-name->username): Use maybe-value-set?. * tests/services/configuration.scm ("maybe type, no default"): Use %unset-value. --- gnu/home/services/ssh.scm | 12 +++++++----- gnu/services/file-sharing.scm | 11 ++++------- gnu/services/getmail.scm | 6 +++--- gnu/services/kerberos.scm | 1 + gnu/services/messaging.scm | 15 ++++++++++----- gnu/services/networking.scm | 2 +- gnu/services/telephony.scm | 6 +++--- tests/services/configuration.scm | 2 +- 8 files changed, 30 insertions(+), 25 deletions(-) diff --git a/gnu/home/services/ssh.scm b/gnu/home/services/ssh.scm index f0987aee23..d15f5ee912 100644 --- a/gnu/home/services/ssh.scm +++ b/gnu/home/services/ssh.scm @@ -69,17 +69,19 @@ (define (serialize-string field value) " " value "\n")) (define (address-family? obj) - (memv obj (list 'unset AF_INET AF_INET6))) + (memv obj (list AF_INET AF_INET6))) + +(define-maybe address-family) (define (serialize-address-family field family) - (if (eq? 'unset family) - "" + (if (maybe-value-set? family) (string-append " " (serialize-field-name field) " " (cond ((= family AF_INET) "inet") ((= family AF_INET6) "inet6") ;; The 'else' branch is unreachable. (else (raise (condition (&error))))) - "\n"))) + "\n") + "")) (define (natural-number? obj) (and (integer? obj) (exact? obj) (> obj 0))) @@ -115,7 +117,7 @@ (define-configuration openssh-host maybe-string "Host name---e.g., @code{\"foo.example.org\"} or @code{\"192.168.1.2\"}.") (address-family - address-family + maybe-address-family "Address family to use when connecting to this host: one of @code{AF_INET} (for IPv4 only), @code{AF_INET6} (for IPv6 only). Additionally, the field can be left unset to allow any address family.") diff --git a/gnu/services/file-sharing.scm b/gnu/services/file-sharing.scm index 5df8b0d597..75e99f20b7 100644 --- a/gnu/services/file-sharing.scm +++ b/gnu/services/file-sharing.scm @@ -114,10 +114,7 @@ (define-maybe string) ;; name-value pair for the JSON builder. (set! serialize-maybe-string (lambda (field-name val) - (serialize-string field-name - (if (eq? val 'unset) - "" - val)))) + (serialize-string field-name (maybe-value val "")))) (define (string-list? val) (and (list? val) @@ -180,9 +177,9 @@ (define (serialize-file-object field-name val) (define-maybe file-object) (set! serialize-maybe-file-object (lambda (field-name val) - (if (eq? val 'unset) - (serialize-string field-name "") - (serialize-file-object field-name val)))) + (if (maybe-value-set? val) + (serialize-file-object field-name val) + (serialize-string field-name "")))) (define (file-object-list? val) (and (list? val) diff --git a/gnu/services/getmail.scm b/gnu/services/getmail.scm index ce124f6b11..0a1c34cfd3 100644 --- a/gnu/services/getmail.scm +++ b/gnu/services/getmail.scm @@ -111,10 +111,10 @@ (define-configuration getmail-retriever-configuration "The type of mail retriever to use. Valid values include @samp{passwd} and @samp{static}.") (server - (string 'unset) + string "Name or IP address of the server to retrieve mail from.") (username - (string 'unset) + string "Username to login to the mail server with.") (port (non-negative-integer #f) @@ -143,7 +143,7 @@ (define (serialize-getmail-destination-configuration field-name val) (define-configuration getmail-destination-configuration (type - (string 'unset) + string "The type of mail destination. Valid values include @samp{Maildir}, @samp{Mboxrd} and @samp{MDA_external}.") (path diff --git a/gnu/services/kerberos.scm b/gnu/services/kerberos.scm index f845c1bd89..c3c7872734 100644 --- a/gnu/services/kerberos.scm +++ b/gnu/services/kerberos.scm @@ -39,6 +39,7 @@ (define-module (gnu services kerberos) +;; TODO Use %unset-value and the define-maybe infrastructure. (define unset-field (list 'unset-field)) (define (predicate/unset pred) diff --git a/gnu/services/messaging.scm b/gnu/services/messaging.scm index 00a1c80a14..59cb486778 100644 --- a/gnu/services/messaging.scm +++ b/gnu/services/messaging.scm @@ -90,6 +90,11 @@ (define (make-pred arg) ((new-def ...) (map (lambda (def target) (if (eq? 'common (syntax->datum target)) + ;; TODO Use the %unset-value variable, or + ;; even better just simplify this so that it + ;; doesn't interfere with + ;; define-configuration and define-maybe + ;; internals. #''unset def)) #'(def ...) #'(target ...))) ((new-doc ...) @@ -200,7 +205,7 @@ (define (serialize-file-object-list field-name val) (define-maybe file-object-list) (define (raw-content? val) - (not (eq? val 'unset))) + (maybe-value-set? val)) (define (serialize-raw-content field-name val) val) (define-maybe raw-content) @@ -474,12 +479,12 @@ (define-all-configurations prosody-configuration global) (http-max-content-size - (maybe-non-negative-integer 'unset) + (maybe-non-negative-integer %unset-value) "Maximum allowed size of the HTTP body (in bytes)." common) (http-external-url - (maybe-string 'unset) + (maybe-string %unset-value) "Some modules expose their own URL in various ways. This URL is built from the protocol, host and port used. If Prosody sits behind a proxy, the public URL will be @code{http-external-url} instead. See @@ -556,7 +561,7 @@ (define-all-configurations prosody-configuration int-component) (mod-muc - (maybe-mod-muc-configuration 'unset) + (maybe-mod-muc-configuration %unset-value) "Multi-user chat (MUC) is Prosody's module for allowing you to create hosted chatrooms/conferences for XMPP users. @@ -573,7 +578,7 @@ (define-all-configurations prosody-configuration ext-component) (raw-content - (maybe-raw-content 'unset) + (maybe-raw-content %unset-value) "Raw content that will be added to the configuration file." common))) diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm index 3c6395b6ca..9d85728371 100644 --- a/gnu/services/networking.scm +++ b/gnu/services/networking.scm @@ -772,7 +772,7 @@ (define-configuration/no-serialization opendht-configuration network. A specific port value can be provided by appending the @code{:PORT} suffix. By default, it uses the Jami bootstrap nodes, but any host can be specified here. It's also possible to disable bootstrapping by explicitly -setting this field to the @code{'unset} value.") +setting this field to @code{%unset-value}.") (port (maybe-number 4222) "The UDP port to bind to. When left unspecified, an available port is diff --git a/gnu/services/telephony.scm b/gnu/services/telephony.scm index 7152f3b38d..624b30116d 100644 --- a/gnu/services/telephony.scm +++ b/gnu/services/telephony.scm @@ -307,7 +307,7 @@ (define (jami-shepherd-services config) (dbus (jami-configuration-dbus config)) (dbus-daemon (file-append dbus "/bin/dbus-daemon")) (accounts (jami-configuration-accounts config)) - (declarative-mode? (not (eq? 'unset accounts)))) + (declarative-mode? (maybe-value-set? accounts))) (with-extensions (list guile-packrat ;used by guile-ac-d-bus guile-ac-d-bus @@ -649,7 +649,7 @@ (define (archive-name->username archive) account-details) (let ((username (archive-name->username archive))) - (when (not (eq? 'unset allowed-contacts)) + (when (maybe-value-set? allowed-contacts) ;; Reject calls from unknown contacts. (set-account-details '(("DHT.PublicInCalls" . "false")) username) @@ -659,7 +659,7 @@ (define (archive-name->username archive) ;; Add allowed ones. (for-each (cut add-contact <> username) allowed-contacts)) - (when (not (eq? 'unset moderators)) + (when (maybe-value-set? moderators) ;; Disable the 'AllModerators' property. (set-all-moderators #f username) ;; Remove all moderators. diff --git a/tests/services/configuration.scm b/tests/services/configuration.scm index 649dad26e8..8ed4ed4b66 100644 --- a/tests/services/configuration.scm +++ b/tests/services/configuration.scm @@ -169,7 +169,7 @@ (define-configuration config-with-maybe-string/no-serialization (not (defined? 'serialize-maybe-string))) (test-assert "maybe type, no default" - (eq? 'unset + (eq? %unset-value (config-with-maybe-string/no-serialization-name (config-with-maybe-string/no-serialization)))) -- 2.35.1 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 24 08:41:28 2022 Received: (at 56799) by debbugs.gnu.org; 24 Aug 2022 12:41:28 +0000 Received: from localhost ([127.0.0.1]:45925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQphI-00082F-0x for submit@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:28 -0400 Received: from mail-ej1-f46.google.com ([209.85.218.46]:44779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQphG-00081r-3r for 56799@debbugs.gnu.org; Wed, 24 Aug 2022 08:41:26 -0400 Received: by mail-ej1-f46.google.com with SMTP id kk26so3570657ejc.11 for <56799@debbugs.gnu.org>; Wed, 24 Aug 2022 05:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc; bh=EuEvu/m9vTXP1uhe7xfafXSMjQnu6BZ8kJH9HxLCMIg=; b=chTo7j83JRFaqHFyCC7W5THZmDZTCu+D4jeWM3q4cWqm6X/LXvUXuADczjmWNEuTiC Fm498iXnt1geNXx1R0AtijztQBbQxtr6l4hCTJW2MQtqVlqdX7vHQ/siIK5xzsbJAeQm Up+/2sRZA5evg2ukRQjIBVqQLbTabHJ2TRS1/JKe5HvnNYisNetKgLqOJwCYU5i4onPl EsGfQPqfwYWIv03sGBTlfsjmWqDcLUqSz92hLkjOFF/unGjQ3cRorYArnpyhBzOj2aO/ xos+8iks7XorcPXNcGbbx6Gm/9yAsOrrXfVjlS4WYLeLhFirKXLNrVlwEoccpG2lQYd0 HzKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-message-state:from :to:cc; bh=EuEvu/m9vTXP1uhe7xfafXSMjQnu6BZ8kJH9HxLCMIg=; b=DVeRI4BU77nA2e4SkpGLIKXcNmlJv6PeHeW/2Jo5XXX1qyiDVq6fE2ZnZENmB3yRs4 u3w0zuQYeNqRVDGDi0FBFP/1LHlvNIhGGMXBEnlZGQ4VdjYpATOumYlBLNC39SxAc7OS 9ISioPl1UF4mGG7xcpX6RGk/WYftuCJBYbG/bT2IjHsvDpN3qE/EG3Dybw4g5b8E7gk6 y+TzwGDZjABGMqXREs2vq1zCTGIy4IfBOI7w3M2i7S7+NIYgMXaWhie9N+r9enF/6US+ 0pCMchG5hdtALze4flaAqXq4pkE6Oj4RLLsXJ5j/Uqqw+e2Lvikypj53lMVU86+kc8UH Njjw== X-Gm-Message-State: ACgBeo2QBLQn0nMsqmS8Ph+WqHcnt0mhORDfBbWl7oyl0zaRv3VJWfvL VFbdE+yR0VUgM9hljuhXH9utKvdDE0w= X-Google-Smtp-Source: AA6agR6FQmqaQAM4kqCtU92y8F1SDmBsuHTws7BgPoOGcqD0R4g7/fDopN8uLrNpmBj5+qpVqI87GA== X-Received: by 2002:a17:907:75f0:b0:73d:c3ca:6731 with SMTP id jz16-20020a17090775f000b0073dc3ca6731mr699666ejc.470.1661344879301; Wed, 24 Aug 2022 05:41:19 -0700 (PDT) Received: from localhost.localdomain ([2a02:ab88:7509:f780:ed82:a496:f55:e07b]) by smtp.gmail.com with ESMTPSA id f2-20020a17090631c200b006fee7b5dff2sm1114628ejf.143.2022.08.24.05.41.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 05:41:18 -0700 (PDT) From: Attila Lendvai To: 56799@debbugs.gnu.org Subject: [PATCH 5/5] services: configuration: Change the value of the unset marker. Date: Wed, 24 Aug 2022 14:40:42 +0200 Message-Id: <20220824124042.10959-5-attila@lendvai.name> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220824124042.10959-1-attila@lendvai.name> References: <20220824124042.10959-1-attila@lendvai.name> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 56799 Cc: Attila Lendvai 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: -0.5 (/) The new value of %unset-value sticks out more when something goes wrong, and is also more unique; i.e. easier to search for. --- gnu/services/configuration.scm | 5 +++-- gnu/services/messaging.scm | 2 +- tests/services/configuration.scm | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index 60965486a7..83da63c1b3 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -305,12 +305,13 @@ (define serialize-package empty-serializer) ;; Ideally this should be an implementation detail, but we export it ;; to provide a simpler API that enables unsetting a configuration -;; field that has a maybe type, but also a default value. +;; field that has a maybe type, but also a default value. We give it +;; a value that sticks out to the reader when something goes wrong. ;; ;; An example use-case would be something like a network application ;; that uses a default port, but the field can explicitly be unset to ;; request a random port at startup. -(define %unset-value 'unset) +(define %unset-value '%unset-marker%) (define (maybe-value-set? value) "Predicate to check whether a 'maybe' value was explicitly provided." diff --git a/gnu/services/messaging.scm b/gnu/services/messaging.scm index 59cb486778..02712ede7c 100644 --- a/gnu/services/messaging.scm +++ b/gnu/services/messaging.scm @@ -95,7 +95,7 @@ (define (make-pred arg) ;; doesn't interfere with ;; define-configuration and define-maybe ;; internals. - #''unset def)) + #''%unset-marker% def)) #'(def ...) #'(target ...))) ((new-doc ...) (map (lambda (doc target) diff --git a/tests/services/configuration.scm b/tests/services/configuration.scm index 8ed4ed4b66..4f8a74dc8a 100644 --- a/tests/services/configuration.scm +++ b/tests/services/configuration.scm @@ -150,7 +150,7 @@ (define-configuration config-with-maybe-symbol (protocol maybe-symbol "")) ;;; Maybe symbol values are currently seen as serializable, because the -;;; unspecified value is 'unset, which is a symbol itself. +;;; unspecified value is '%unset-marker%, which is a symbol itself. ;;; TODO: Remove expected fail marker after resolution. (test-expect-fail 1) (test-equal "symbol maybe value serialization, unspecified" -- 2.35.1 From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 25 00:14:40 2022 Received: (at 56799-done) by debbugs.gnu.org; 25 Aug 2022 04:14:40 +0000 Received: from localhost ([127.0.0.1]:48568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oR4GO-00036g-5P for submit@debbugs.gnu.org; Thu, 25 Aug 2022 00:14:40 -0400 Received: from mail-qk1-f182.google.com ([209.85.222.182]:37812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oR4GM-00036S-A4 for 56799-done@debbugs.gnu.org; Thu, 25 Aug 2022 00:14:38 -0400 Received: by mail-qk1-f182.google.com with SMTP id a15so14298381qko.4 for <56799-done@debbugs.gnu.org>; Wed, 24 Aug 2022 21:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=O7MgpjUAhuZb2hdn91nwJeIOIV1NVQVFTl+tDlXxxgg=; b=BnZBqD0iGCTQir8YHuBEnhRFMlB9gRLcix1p9M9dkXwn+7W5uVD6Ar4vra2CICM9A/ 7dTIastCRTU4J39/RdBtd5ihVSDnb7YYob74F9LrD1fdLZI01gpoz9YdFLI57jFfOKaz LOwgAlGA3ANdUAqI1H/+5DbBnaMImbT0O6trb66lCa6g5qg/ZOYDXYrqmtBMREP3ewhq RFMD0eo1qYFR5S0Jc8jODnqJ+RD1ljCxcZCvQMHe/q+KJJk7vut+f1ly6+KdDHI/Npg8 12Y4ibIw/KOQUYUn7bRmttnJJmJhNDHrCm1CF1AfCOidxp6znqwzZBU85c3iqnzAQ41w zXdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=O7MgpjUAhuZb2hdn91nwJeIOIV1NVQVFTl+tDlXxxgg=; b=1yIr9N2TqfphvsOCZ5xdZxGBtFjpsYXcKmvNhPRJU4XttzOhN0f+rbDHyMb9XxCTS0 hQsyrLsA/73tWQ8wxTayZsmgOni4TyVb5QXqQHeORg9712F/4eXedor7JTQwfHGvsIiO 8VyBtGwY4OtetS8x6d41xKiL7PLKMaVSN21WbLNliA1vXn1Wbu2279R/+EOc+NCNNTYl Tau2U06SmLxkxpLjlbqTGZUua8ZUWxhtAi9NAc5faWSRa8joebpL1Mse9xBTMwbEjd0X FlvnvsiybmRT22gOfcSGMEKa1EEzTlNBxGAzGEG0K4rmmcsD8KqZfSIy00JpWt8uAlGw YX1Q== X-Gm-Message-State: ACgBeo2ID0h9bId6eLNSSHcRWsC5ex1IgW0thiojmozQrTO5FWi4gFdB VtN4Bv/yLPTJS5sguk2W9QacCLay9Is= X-Google-Smtp-Source: AA6agR7XElQV7JATUx9NChrQbu7LgANo6PwkAx/TjasGhOfuyjo0cKOcBMY1rAABa71MqeA6YmnLYw== X-Received: by 2002:a37:5e41:0:b0:6b9:19c4:70cf with SMTP id s62-20020a375e41000000b006b919c470cfmr1771876qkb.348.1661400872539; Wed, 24 Aug 2022 21:14:32 -0700 (PDT) Received: from hurd (dsl-10-129-95.b2b2c.ca. [72.10.129.95]) by smtp.gmail.com with ESMTPSA id de39-20020a05620a372700b006b999c1030bsm15960314qkb.52.2022.08.24.21.14.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 21:14:31 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <20220824124042.10959-1-attila@lendvai.name> <20220824124042.10959-5-attila@lendvai.name> Date: Thu, 25 Aug 2022 00:14:30 -0400 In-Reply-To: <20220824124042.10959-5-attila@lendvai.name> (Attila Lendvai's message of "Wed, 24 Aug 2022 14:40:42 +0200") Message-ID: <875yihez89.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799-done Cc: 56799-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 (-) Hi Attila, Attila Lendvai writes: > The new value of %unset-value sticks out more when something goes wrong, and > is also more unique; i.e. easier to search for. > --- > gnu/services/configuration.scm | 5 +++-- > gnu/services/messaging.scm | 2 +- > tests/services/configuration.scm | 2 +- > 3 files changed, 5 insertions(+), 4 deletions(-) Thanks for the series! I've now pushed all of the 5 commits. Yay! Closing! Maxim From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 25 00:18:49 2022 Received: (at 56799-done) by debbugs.gnu.org; 25 Aug 2022 04:18:49 +0000 Received: from localhost ([127.0.0.1]:48575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oR4KO-0003DX-SK for submit@debbugs.gnu.org; Thu, 25 Aug 2022 00:18:49 -0400 Received: from mail-qv1-f44.google.com ([209.85.219.44]:33560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oR4KJ-0003DH-Hr for 56799-done@debbugs.gnu.org; Thu, 25 Aug 2022 00:18:47 -0400 Received: by mail-qv1-f44.google.com with SMTP id d1so14507940qvs.0 for <56799-done@debbugs.gnu.org>; Wed, 24 Aug 2022 21:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc; bh=Cy0U+34yxKon6k2ziBZyUGIJVOLduTw4nkx+k+8gC78=; b=cwHU+8GpljognBMmzDCbF2ynNZA126O8+Ma86CoUf2jCkndc4OEfDPfwQcy3JglnuX EIUtoCfCBurO0FmB0N1ECNHz/MPJ4A09poWX0nvuggTkiejpSxmljPuckpBBrtZ7NPhR en0Fnl/NNEIbGd5JfgOsybFO8ZUEj9G90mKv5LPMXkw4HPa99EewdEFbFMTqneXWDX6P aQyja8AMOLDKMBRmnigZi5xzKqLTztKkRiliVnWb4ZPlp5EIpol7LhmACEycHyPcI2Ux MsM+kXYju/YrX1w+LsrOR/d7JCvZCP9pOWKFUGQR879eDpufGho1LVVd+fHEFrjJWg0b RIWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc; bh=Cy0U+34yxKon6k2ziBZyUGIJVOLduTw4nkx+k+8gC78=; b=LCPc++50i2Nf73DDi01QjyK65hLD652d+Luzz1IUZrMOg12rSmVdeO4TMOAF0mBQF1 oI2Tvof/QoUfQyMFKpWDayIHVzbdjnmPDmgjDJ/ZMYrSs5CjMPstnHCc9cML7T1GVKnI 8PUHK6rKwaMM86sL31/pfgvAZaESInlkbUEWV9HZ7GHkPPZs+Mb2TE2GUkmTI4HJyqr+ yY4EVo8dY3IjGg1hQx9C3rC3bo3y51NVpa+TG8YYxXXD0+CWrmNQXCiUzZo6HtmIJjyj w7A+r9ci4RYQze1RbXIgDqoLI2j8J28v8du/GRQvtwMyOX8Ru8BFxCgwbEEhuB6mmUMc gCTQ== X-Gm-Message-State: ACgBeo0S3zCoifPHFyt0y7A1dbF6Sno5zQIXUcrdX/etnlsUu5T1fTu/ a+NUFP+USgoKzfHxxnJ7Gpg41XwYfe8= X-Google-Smtp-Source: AA6agR5ULQLN/3fYMMlZwa02N/9spQ/nmOAb6TwLcUWmwvxWaV8QnGJFhLVMyZXQvfj5IQSbtEGTNQ== X-Received: by 2002:ad4:5d6a:0:b0:476:cf69:fa18 with SMTP id fn10-20020ad45d6a000000b00476cf69fa18mr2137787qvb.22.1661401117726; Wed, 24 Aug 2022 21:18:37 -0700 (PDT) Received: from hurd (dsl-10-129-95.b2b2c.ca. [72.10.129.95]) by smtp.gmail.com with ESMTPSA id t13-20020a05622a01cd00b00342f8143599sm14224738qtw.13.2022.08.24.21.18.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Aug 2022 21:18:37 -0700 (PDT) From: Maxim Cournoyer To: Attila Lendvai Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic References: <20220824124042.10959-1-attila@lendvai.name> <20220824124042.10959-4-attila@lendvai.name> Date: Thu, 25 Aug 2022 00:18:36 -0400 In-Reply-To: <20220824124042.10959-4-attila@lendvai.name> (Attila Lendvai's message of "Wed, 24 Aug 2022 14:40:41 +0200") Message-ID: <874jy1ez1f.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56799-done Cc: 56799-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 (-) Hi, Attila Lendvai writes: > * gnu/home/services/ssh.scm (serialize-address-family): Use the public AP= I of > the maybe infrastructure. > * gnu/services/file-sharing.scm (serialize-maybe-string): Use maybe-value. > (serialize-maybe-file-object): Use maybe-value-set?. > * gnu/services/getmail.scm (getmail-retriever-configuration): Don't use > internals in unset field declarations. > (getmail-destination-configuration): Ditto. > * gnu/services/messaging.scm (raw-content?): Use maybe-value-set?. > (prosody-configuration): Use %unset-value. > * gnu/services/telephony.scm (jami-shepherd-services): Use maybe-value-se= t?. > (archive-name->username): Use maybe-value-set?. > * tests/services/configuration.scm ("maybe type, no default"): Use > %unset-value. [...] > --- a/gnu/services/telephony.scm > +++ b/gnu/services/telephony.scm > @@ -307,7 +307,7 @@ (define (jami-shepherd-services config) > (dbus (jami-configuration-dbus config)) > (dbus-daemon (file-append dbus "/bin/dbus-daemon")) > (accounts (jami-configuration-accounts config)) > - (declarative-mode? (not (eq? 'unset accounts)))) > + (declarative-mode? (maybe-value-set? accounts))) >=20=20 > (with-extensions (list guile-packrat ;used by guile-ac-d-bus > guile-ac-d-bus > @@ -649,7 +649,7 @@ (define (archive-name->username archive) > account-details) > (let ((username (archive-name->username > archive))) > - (when (not (eq? 'unset allowed-contacts)) > + (when (maybe-value-set? allowed-contacts) > ;; Reject calls from unknown contacts. > (set-account-details > '(("DHT.PublicInCalls" . "false")) usern= ame) > @@ -659,7 +659,7 @@ (define (archive-name->username archive) > ;; Add allowed ones. > (for-each (cut add-contact <> username) > allowed-contacts)) > - (when (not (eq? 'unset moderators)) > + (when (maybe-value-set? moderators) > ;; Disable the 'AllModerators' property. > (set-all-moderators #f username) > ;; Remove all moderators. maybe-value-set? cannot be used there, as the code runs on the target, not on the host, where (gnu services configuration) is not (and cannot) be in scope. I've made the simple change below and pushed: --8<---------------cut here---------------start------------->8--- modified gnu/services/telephony.scm @@ -649,7 +649,7 @@ (define (archive-name->username archive) account-details) (let ((username (archive-name->username archive))) - (when (maybe-value-set? allowed-contacts) + (when (not (eq? '#$%unset-value allowed-conta= cts)) ;; Reject calls from unknown contacts. (set-account-details '(("DHT.PublicInCalls" . "false")) usernam= e) @@ -659,7 +659,7 @@ (define (archive-name->username archive) ;; Add allowed ones. (for-each (cut add-contact <> username) allowed-contacts)) - (when (maybe-value-set? moderators) + (when (not (eq? '#$%unset-value moderators)) ;; Disable the 'AllModerators' property. (set-all-moderators #f username) ;; Remove all moderators. --8<---------------cut here---------------end--------------->8--- I've also adjusted a few 'unset mentions in the doc: --8<---------------cut here---------------start------------->8--- modified doc/guix.texi @@ -19846,7 +19846,7 @@ network. A specific port value can be provided by = appending the @code{:PORT} suffix. By default, it uses the Jami bootstrap nodes, but any host can be specified here. It's also possible to disable bootstrapping by explicitly setting this field to the -@code{'unset} value. +@code{%unset-value} value. =20 @item @code{port} (default: @code{4222}) (type: maybe-number) The UDP port to bind to. When left unspecified, an available port is @@ -31362,7 +31362,7 @@ Each parameter definition is preceded by its type; = for example, @samp{boolean foo} indicates that the @code{foo} parameter should be specified as a boolean. Types starting with @code{maybe-} denote parameters that won't show up in TLP config file when their value is -left unset, or is explicitly set to the @code{'unset} value. +left unset, or is explicitly set to the @code{%unset-value} value. =20 @c The following documentation was initially generated by @c (generate-tlp-documentation) in (gnu services pm). Manually maintained @@ -38983,8 +38983,7 @@ macro which is a shorthand of this. Sometimes a field should not be serialized if the user doesn=E2=80=99t spe= cify a value. To achieve this, you can use the @code{define-maybe} macro to define a ``maybe type''; if the value of a maybe type is left unset, or -is set to the @code{'unset} value, then it will not be -serialized. +is set to the @code{%unset-value} value, then it will not be serialized. =20 When defining a ``maybe type'', the corresponding serializer for the regular type will be used by default. For example, a field of type --8<---------------cut here---------------end--------------->8--- I've made these changes and pushed, as mentioned in a previous email. Thank you! Maxim From unknown Thu Aug 14 20:51:47 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 22 Sep 2022 11:24:09 +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