| Age | Commit message (Collapse) | Author |
|---|
|
This is added for convenience and for uniformity with the
define-maybe/no-serialization syntax introduced in the previous commit.
* gnu/services/configuration.scm
(define-configuration/no-serialization): New syntax.
|
|
Before this change, using define-maybe along define-configuration with the
no-serialization syntactic keyword would result in the following warning:
warning: possibly unbound variable `VARIABLE-NAME'
This change introduces the define-maybe/no-serialization variant that does
away with defining a serialization helper procedure, which makes it possible
to avoid the above warning.
* gnu/services/configuration.scm (define-maybe/no-serialization): New syntax.
(define-maybe-helper): New procedure.
(define-maybe): Define syntax using the above procedure.
* tests/services/configuration.scm (tests): Fix module name.
(custom-number-serializer): Do not print to standard output.
(maybe-number?, serialize-maybe-number): New procedures defined via the
define-maybe macro.
(config-with-maybe-number): New configuration.
(serialize-number): New procedure.
("maybe value serialization"): New test.
(maybe-string?): New procedure defined via the define-maybe/no-serialization
macro.
(config-with-maybe-string/no-serialization): New configuration.
("maybe value without serialization no procedure bound"): New test.
|
|
This is a followup to 3f9a12dc082b20426fc740416601b69ea1897193.
* gnu/services/configuration.scm (no-serialization): New variable.
|
|
The non-hygienic binding of the source location accessor was set to
'-location'; in modules where multiple configurations were defined, it would
cause compilation warnings such as:
gnu/services/mail.scm:175:0: warning: shadows previous definition of
`%-location-procedure' at gnu/services/mail.scm:165:0
* gnu/services/configuration.scm (define-configuration-helper) <id>: Add a
missing #'stem argument to use the configuration name as a prefix to the
location accessor identifier.
|
|
In some cases, rather than globally disabling serialization, it may be more
appropriate to disable or otherwise alter the serialization procedure of a
specific field. In large module, multiple configurations may also exist that
would need to alter the default serialization procedure, which is named after
the field type. Being able to specify a per-field serialization procedure
provides more flexibility.
* gnu/services/configuration.scm (define-configuration): Add an optional
pattern variable to allow specifying a custom serialization procedure.
(define-configuration-helper) <field-serializer>: Use it to transform the
syntax.
(empty-serializer): New procedure.
(serialize-package): Alias to ‘empty-serializer’.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
|
|
Serialization is not always useful, for example when deriving command line
arguments from a configuration. This change provides a way to turn it off,
which removes the need to define a bunch of dummy serialization procedures.
Credit goes to Andrew Gierth (RhodiumToad) from #guile for providing the
solution. Thank you!
* gnu/services/configuration.scm (define-configuration-helper): New procedure.
(define-configuration) <no-serialization>: New syntactic keyword. Use it in a
new pattern. Refactor the macro so that it makes use of the above helper
procedure.
|
|
This resolves a compilation warning introduced with commit bb716e8d9d.
* gnu/services/configuration.scm (configuration->documentation): Use display
to print the string instead of format.
|
|
The original (undocumented) procedure to generate the doc has a difficult to
grasp interface; add a simpler one on top of it.
* gnu/services/configuration.scm (configuration->documentation): New procedure.
|
|
Not all fields in a configuration have a sensible default value. This changes
makes it possible to omit a default value for a configuration field, requiring
the user to provide a value.
* gnu/services/configuration.scm (configuration-missing-field): New procedure.
(define-configuration): Make default value optional.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
|
