Hi, Robert Vollmert <r...@vllmrt.net> skribis:
>> On 7. Jul 2019, at 16:24, Ludovic Courtès <l...@gnu.org> wrote: >> >> Hi Robert, >> >> Robert Vollmert <r...@vllmrt.net> 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 same. 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 info. 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. Thanks, Ludo’.
