[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56799: closed ((gnu services configuration) usage of *unspecified* i

From: GNU bug Tracking System
Subject: bug#56799: closed ((gnu services configuration) usage of *unspecified* is problematic)
Date: Mon, 01 Aug 2022 16:56:02 +0000

Your message dated Mon, 01 Aug 2022 12:55:19 -0400
with message-id <87czdj3nuw.fsf@gmail.com>
and subject line Re: bug#56799: (gnu services configuration) usage of 
*unspecified* is problematic
has caused the debbugs.gnu.org bug report #56799,
regarding (gnu services configuration) usage of *unspecified* is problematic
to be marked as done.

(If you believe you have received this mail in error, please contact

56799: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56799
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: (gnu services configuration) usage of *unspecified* is problematic Date: Wed, 27 Jul 2022 12:23:58 -0400
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
                 (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: #<unspecified>: 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 
 (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: #<unspecified>: 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.




--- End Message ---
--- Begin Message --- Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Date: Mon, 01 Aug 2022 12:55:19 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Hi Maxim,
> Maxim Cournoyer 写道:
>> 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… in the above context I'd hesitate to even imply
> ‘semantics’. 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

I also added a 'jami-provisioning-partial' system test to ensure it
doesn't regress again if we decide to revisit this.




--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]