guix-patches
[Top][All Lists]
Advanced

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

bug#36875: [PATCH] doc: Document the use of `program-file' for mcron job


From: Maxim Cournoyer
Subject: bug#36875: [PATCH] doc: Document the use of `program-file' for mcron jobs.
Date: Mon, 26 Aug 2019 07:54:58 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hello Ludovic!

Ludovic Courtès <address@hidden> writes:

> Hello!
>
> Maxim Cournoyer <address@hidden> skribis:
>
>> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <address@hidden>
>> Date: Thu, 1 Aug 2019 07:34:17 +0900
>> Subject: [PATCH] doc: Document the use of `program-file' for mcron jobs.
>>
>> * doc/guix.texi (Scheduled Job Execution): Explain why using `program-file'
>> for an mcron job can be necessary.  Add an example.
>
> [...]
>
>> +For more complex jobs defined in Scheme, it is safer to pass the job as a
>> +script to mcron; otherwise, macros defined or imported with 
>> @code{use-modules}
>> +wouldn't expand correctly, as Guile requires macros to be strictly defined 
>> or
>> +imported at the top level of a Guile module.  This can be achieved using the
>> +@code{program-file} procedure from the @code{(guix gexp)} module, as shown 
>> in
>> +the example below.
>
> Macros are a very good example of the problem, but I wonder if it would
> be clearer to simply write something like:
>
>   For more complex jobs defined in Scheme where you need control over
>   the top level, for instance to introduce a @code{use-modules} form, you
>   can move your code to a separate program using the @code{program-file}
>   procedure of the @code{(guix gexp)} module (@pxref{G-Expressions}).
>   The example below illustrates that.

I like your version, which feels to me more elegant. But, from my
experimentation, using (use-modules) in a nested form is fine for
anything else than syntax (macros).  Also, the Guile Reference only says
that macros must be *defined* at the top level; it doesn't explicitly
mention that importing macros is equivalent to defining macros, and are
thus subjected to the same restrictions.  So, I've amended it to mention
the problem more precisely:

--8<---------------cut here---------------start------------->8---
For more complex jobs defined in Scheme where you need control over the top
level, for instance to introduce a @code{use-modules} form that defines syntax
(macros), you can move your code to a separate program using the
@code{program-file} procedure of the @code{(guix gexp)} module
(@pxref{G-Expressions}).  The example below illustrates that.
--8<---------------cut here---------------end--------------->8---

> Anyway, your patch looks like a great improvement (and a funny example
> :-)) so IMO you should push one version or another!

This is now live as commit 1407ebeaa1.  Thanks for feedback/review! :-)

Maxim





reply via email to

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