From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 36875-done@debbugs.gnu.org
Subject: [bug#36875] [PATCH] doc: Document the use of `program-file' for mcron jobs.
Date: Tue, 27 Aug 2019 19:59:25 +0900 [thread overview]
Message-ID: <87o90aeuwi.fsf@gmail.com> (raw)
In-Reply-To: <87mufw1g8e.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 26 Aug 2019 10:30:09 +0200")
Hello Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello!
>>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
>>>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>>>> 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.
[...]
>>> 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).
>
> That’s right, but I strongly recommend not relying on non-toplevel
> ‘use-modules’ because (1) it’s “ugly” because it introduces new bindings
> at run time, and (2) it’s not guaranteed to work in the future—in fact,
> the just-released Guile 2.9.4 introduces “declarative modules”, which is
> probably a first step in the direction of less run-time trickery with
> modules.
Oh! That's good to know! Then using your proposed text as-is makes
even more sense. Done in commit 4183105de0.
Thank you!
Maxim
prev parent reply other threads:[~2019-08-27 2:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 0:27 [bug#36875] [PATCH] doc: Document the use of `program-file' for mcron jobs Maxim Cournoyer
2019-07-31 19:39 ` Ricardo Wurmus
2019-08-02 0:03 ` Maxim Cournoyer
2019-08-17 20:06 ` Ludovic Courtès
2019-08-25 22:54 ` bug#36875: " Maxim Cournoyer
2019-08-26 8:30 ` [bug#36875] " Ludovic Courtès
2019-08-27 10:59 ` Maxim Cournoyer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o90aeuwi.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=36875-done@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).