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