GNU bug report logs - #36875
[PATCH] doc: Document the use of `program-file' for mcron jobs.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36875 in the body.
You can then email your comments to 36875 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: guix-patches <guix-patches <at> gnu.org>
Subject: [PATCH] doc: Document the use of `program-file' for mcron jobs.
Date: Thu, 01 Aug 2019 09:27:45 +0900

[Message part 1 (text/plain, inline)]

Hello!

This follows up to my second post under the thread at
(https://lists.gnu.org/archive/html/help-guix/2019-07/msg00180.html).

It aims to shed some light on (more) complex mcron job Guile scripting
with the aid of Guix features (such as program-file).

[0001-doc-Document-the-use-of-program-file-for-mcron-jobs.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

Thanks,

Maxim

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 36875 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 36875 <at> debbugs.gnu.org
Subject: Re: [bug#36875] [PATCH] doc: Document the use of `program-file' for
 mcron jobs.
Date: Wed, 31 Jul 2019 21:39:37 +0200

Hi Maxim,

> This follows up to my second post under the thread at
> (https://lists.gnu.org/archive/html/help-guix/2019-07/msg00180.html).
>
> It aims to shed some light on (more) complex mcron job Guile scripting
> with the aid of Guix features (such as program-file).

I wonder if this can be worked around some other way, e.g. by adding
srfi-26 to the “with-imported-modules” clause.

I don’t fully understand the problem as described in the addition to the
manual.  What does “imported syntax definitions wouldn't work correctly”
mean?

It would be useful to state that this is something to do with srfi-26.

About the patch:

- please replace tabs with spaces.

- “Beep the system when the battery reaches %MIN-LEVEL or less battery
  percent.” sounds odd.  How about “Beep when the battery percentage
  falls below %MIN-LEVEL.”?

- Can the example be simplified further?  Is (setenv "LC_ALL" "C")
  really needed here?

- instead of let* and when I’d probably use and-let*.

--
Ricardo

Message #11 received at 36875 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 36875 <at> debbugs.gnu.org
Subject: Re: [bug#36875] [PATCH] doc: Document the use of `program-file' for
 mcron jobs.
Date: Fri, 02 Aug 2019 09:03:54 +0900

[Message part 1 (text/plain, inline)]

Hello Ricardo!

Ricardo Wurmus <rekado <at> elephly.net> writes:

> Hi Maxim,
>
>> This follows up to my second post under the thread at
>> (https://lists.gnu.org/archive/html/help-guix/2019-07/msg00180.html).
>>
>> It aims to shed some light on (more) complex mcron job Guile scripting
>> with the aid of Guix features (such as program-file).
>
> I wonder if this can be worked around some other way, e.g. by adding
> srfi-26 to the “with-imported-modules” clause.

No; srfi-26 is already present in the Guile load
path. `with-imported-modules' is used to import non-builtin Guile
modules into the generated script load paths. In the current example,
passing (srfi srfi-26) to (with-imported-modules ...) doesn't change the
hash of the compiled gexps (because it is already included).

> I don’t fully understand the problem as described in the addition to the
> manual.  What does “imported syntax definitions wouldn't work correctly”
> mean?

That any macro imported with (use-modules ...) in a mcron job defined
using a lambda would not be expanded correctly.

> It would be useful to state that this is something to do with srfi-26.

It is not just about srfi-26; but about any syntax definitions (macros) that a
user might want to use in a mcron script, such as `guard' from
srfi-34. Consider the mcron job defined as below:

--8<---------------cut here---------------start------------->8---
(define %macros-in-a-mcron-lambda-job-dont-work
  (with-imported-modules (source-module-closure
			  '((guix build utils)))
    #~(job
       '(next-minute (range 0 60 1))
       (lambda _
	 (use-modules (guix build utils)
		      (srfi srfi-34))
	 (guard (c ((invoke-error? c))
		   (format #t "Guard worked as expected."))
	   (invoke "false"))))))
--8<---------------cut here---------------end--------------->8---

Then upon running, it would fail with the following backtrace:

--8<---------------cut here---------------start------------->8---
Backtrace:
           9 (apply-smob/1 #<catch-closure 19e7300>)
In ice-9/boot-9.scm:
    829:9  8 (catch _ _ #<procedure 7f858dc5ed38 at mcron/scripts/m?> ?)
In mcron/scripts/mcron.scm:
     99:7  7 (_)
In mcron/base.scm:
   234:12  6 (_ #<continuation 19d3020>)
In srfi/srfi-1.scm:
    640:9  5 (for-each #<procedure run-job (job)> (#<<job> user: #(?>))
In mcron/base.scm:
   186:10  4 (run-job _)
In ice-9/eval.scm:
    159:9  3 (_ #(#(#<directory (mcron scripts mcron) 1ac1c80>) ()))
   182:19  2 (proc #(#(#<directory (mcron scripts mcron) 1ac1c80>) #))
   142:16  1 (compile-top-call _ (7 . c) ((10 (10 (13 15 . #) #)) #))
In unknown file:
           0 (%resolve-variable (7 . c) #<directory (mcron scripts m?>)

ERROR: In procedure %resolve-variable:
Unbound variable: c
--8<---------------cut here---------------end--------------->8---

Which I found quite puzzling, and can easily imagine other mcron users
stumbling onto.  The solution (to use the program-file Gexp facility) is
not an obvious one, so is worth being documented, in my opinion. I've
attempted to clarify the text is the revised patch (attached).

> About the patch:
>
> - please replace tabs with spaces.

Done.

> - “Beep the system when the battery reaches %MIN-LEVEL or less battery
>   percent.” sounds odd.  How about “Beep when the battery percentage
>   falls below %MIN-LEVEL.”?

Done (and modified the logic to match it).
)
> - Can the example be simplified further?  Is (setenv "LC_ALL" "C")
>   really needed here?

It's to ensure that the output of the 'acpi' command is in English,
which the script depends on (setting the locale of the system to
something else could affect this, if acpi is internationalized (I don't
know, but I'm protecting against it, in case)).

> - instead of let* and when I’d probably use and-let*.

Done.

Reworked patch is attached.

Thanks for the feedback! :-)

Maxim

[0001-doc-Document-the-use-of-program-file-for-mcron-jobs.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 36875 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 36875 <at> debbugs.gnu.org
Subject: Re: [bug#36875] [PATCH] doc: Document the use of `program-file' for
 mcron jobs.
Date: Sat, 17 Aug 2019 22:06:44 +0200

Hello!

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> 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.

[...]

> +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.

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

Thanks,
Ludo’.

Message #19 received at 36875-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 36875-done <at> debbugs.gnu.org
Subject: Re: [bug#36875] [PATCH] doc: Document the use of `program-file' for
 mcron jobs.
Date: Mon, 26 Aug 2019 07:54:58 +0900

Hello Ludovic!

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> 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.
>
> [...]
>
>> +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

Message #22 received at 36875-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 36875-done <at> debbugs.gnu.org
Subject: Re: [bug#36875] [PATCH] doc: Document the use of `program-file' for
 mcron jobs.
Date: Mon, 26 Aug 2019 10:30:09 +0200

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hello!
>>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>
>>> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
>>> From: Maxim Cournoyer <maxim.cournoyer <at> 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.
>>
>> [...]
>>
>>> +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).

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.

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

Great, thank you!

Ludo’.

Message #25 received at 36875-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 36875-done <at> debbugs.gnu.org
Subject: Re: [bug#36875] [PATCH] doc: Document the use of `program-file' for
 mcron jobs.
Date: Tue, 27 Aug 2019 19:59:25 +0900

Hello Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hello!
>>>
>>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>>
>>>> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
>>>> From: Maxim Cournoyer <maxim.cournoyer <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.