GNU bug report logs -
#69591
[PATCH 00/31] Unbundle and update python-pytorch
Previous Next
Full log
Message #413 received at 69591 <at> debbugs.gnu.org (full text, mbox):
Hi Maxim,
(Cc’ing 71739, which is actually the right one. :-))
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> Ludovic Courtès <ludo <at> gnu.org> writes:
[...]
>> +@item @code{free-form} (default: @code{#f})
>> +When set, this field replaces the @code{start}, @code{stop}, and
>> +@code{actions} fields. It is meant to be used when the service
>> +definition comes from some other source, typically the service
>> +collection provided by the Shepherd proper (@pxref{Service Collection,,,
>> +shepherd, The GNU Shepherd Manual}).
>> +
>> +@cindex REPL service, for shepherd
>> +For example, the snippet below defines a service for the Shepherd's
>> +built-in @acronym{REPL, read-eval-print loop} service (@pxref{REPL
>> +Service,,, shepherd, The GNU Shepherd Manual}):
>> +
>> +@lisp
>> +(shepherd-service
>> + (provision '(repl))
>> + (modules '((shepherd service repl)))
>> + (free-form #~(repl-service)))
>> +@end lisp
[...]
> Hm, if free-form is expected to be a built-in procedure provided by
> Shepherd, should we call it 'built-in' instead of 'free-form' ?
I view it as something more generic: it’s typically, but not just, for
when the service comes from a procedure defined in the Shepherd itself.
Other use case is when as a service author you need more freedom that
what you get with the ‘start’ and ‘stop’ fields, like:
(shepherd-service
;; …
(free-from #~(let ((whatever (spawn-fiber …)))
(service '(foo) #:start …))))
It’s probably going to be a relatively marginal use case, but it’s good
to have that extra level of flexibility.
WDYT?
Thanks!
Ludo’.
This bug report was last modified 1 year and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.