bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi, Attila Lendvai writes: > * 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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 |

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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?`?

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

> > 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... :)

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

> 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

> 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi, Ludovic Courtès 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

> 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

i got back online... > That said, whether it’s ‘unspecified?’ 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’s possible

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hello, I just hit this while running ‘guix home reconfigure’ from f0ae9da3210cc6d87ca519545203daf9751f3465: home-config.scm:24:16: error: invalid value unset for field 'address-family' It’s an ‘openssh-host’ record: (openssh-host (name "xyz") (host-name "xyz.example.org") (user

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Howdy, Maxim Cournoyer skribis: >>> Granted, few services outside of Jami probably made use of this, but it >>> was nevertheless a useful property. >> >> I don’t know of any. > > I think mostly because few services make use of define-configuration. > While attempting to write a new VNC service,

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi Ludovic, Ludovic Courtès writes: [...] >> Granted, few services outside of Jami probably made use of this, but it >> was nevertheless a useful property. > > I don’t know of any. I think mostly because few services make use of define-configuration. While attempting to write a new VNC

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi, Tobias Geerinckx-Rice 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi Ludo, 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,

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi! Maxim Cournoyer skribis: > Fixes . > > * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encountering it. I think we need to take a step back. Overall, I’m reluctant to modifying a core primitive like ‘gexp->sexp’ “just” to address this

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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:

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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,

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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,

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

On 28-07-2022 06:55, b...@bokr.com wrote: Lots of systems are dealing with this issue, it seems, judging from [1]https://en.wikipedia.org/wiki/Bottom_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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

Hi, Tobias Geerinckx-Rice 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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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. it used to be 'DISABLED, which was even worse as it can be confused/conflated with

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

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: