[Top][All Lists]

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

bug#36430: mcron would benefit from a better way to test jobs

From: Ludovic Courtès
Subject: bug#36430: mcron would benefit from a better way to test jobs
Date: Mon, 08 Jul 2019 11:54:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)


Robert Vollmert <address@hidden> skribis:

>> On 7. Jul 2019, at 16:24, Ludovic Courtès <address@hidden> wrote:
>> Hi Robert,
>> Robert Vollmert <address@hidden> skribis:
>>> Defined a mcron job in config.scm scheduled to run once a day,
>>> with a scheme expression. How do I test this?
>>> herd schedule mcron lists the job as merely a “Lambda expression”.
>>> I learned how to give it a descriptive name, but still there’s
>>> no script linked that I can run by hand.
>> Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
>> in a simple way so we see an actual command rather than “Lambda
>> expression”.  I would recommend using this style to improve
>> transparency.
> I understand that passing an executable works better. But that also
> loses the feature of allowing to write a script in place advertised by
> the lambda variant.

In Guix, if you write:

  #~(job … #$(program-file "do-something" #~(begin …)))

instead of:

  #~(job … (lambda () …))

you’re still writing Scheme code, and the result is pretty much the

Now, from a pure mcron viewpoint (if you were to use it outside Guix), I
agree that procedures are handled in a suboptimal way.  Mcron should
simply display the procedure object, which includes its source location

Aternately it could display its source location info as obtained with
‘program-source’ if that helps readability:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(system vm program)
scheme@(guile-user)> (program-source derivation (program-code derivation))
$6 = (2780 "guix/derivations.scm" 877 . 17)
--8<---------------cut here---------------end--------------->8---

> I find that kind of “feature that doesn’t actually work” to be quite
> painful.
> A way to get the best of both worlds (within guix) would be to use
> program-file / gexp, so maybe that’s what should be advertised in the
> guix manual?

Yes, definitely.

> At this stage, there’s just too many small hacking sessions required
> all over the place :). I’ll stick with filing bug reports for the
> clear pain points if that’s ok?

Sure, definitely!  It’s good to have all these pain points filed, and I
think many can be addressed quite easily, so that’ll help us improve
things gradually.


reply via email to

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