IRC channel logs

<zimoun>Article speaking about Guix https://www.nature.com/articles/s41597-022-01720-9

<rekado>woo, congratulations!

<civodul>yay, well done!

<rekado>is this the first time to see Guix in a Nature article?

<zimoun>rekado: I do not know. We had many refusals and it would be interesting to write another article about the process. :-)

<civodul>"The Guix system is implemented using the Scheme language21"

<civodul>... and footnote 21 is about Common Lisp :-)

<drakonis>hah

<drakonis>that's a huge step forward

<drakonis>should've linked to r5rs

<zimoun>oups! That’s what happens when you delegate.

<zimoun>initially, it was a reference to the Guile Manual. Hum, something lost in transalation.

<old>Talking about publication, what would be the best way to publish with Guix?

<old>I've been using guix and gwl in the past months for my research and I'm starting to write my thesis next month. I'm not sure how to incorporate the Guix stuff in the article

<old>Like, should I provide the pinned channels for reproducibility in the annexes?

<zimoun>old, yes that’s what I would recommend: channels.scm and manifest.scm files and mention “guix time-machine -C channels.scm -- shel -m manifest.scm”.

<zimoun>For complex configuration using your packages, the command-line and/or manifest.scm can be complex.

<rekado>you can use gwl also with the time machine, can’t you?

<rekado>IIRC it will always use the same Guix that launched it

<rekado>so “guix time-machine -C channels.csm -- workflow …” should work fine

<rekado>then all you need to do is include the workflow files and the channels.scm

<rekado>old: I’m going to merge lilyp’s patch to use manifests instead of a list of packages. Would be good if you could test that this doesn’t break things for you.

<old>rekado: Yes I think that manifest entry would be a better thing. Where can I find the patches?

<old>Okay so just giving the workflow file and the channel definition should be enough in the paper thank you.

<rekado>Message-ID: <581bd6f4ad0b5258152b2ae9804f6cd866876984.camel@ist.tugraz.at> on gwl-devel

<old>rekado: awesome thanks. I'll try it today

<rekado>thank you!

<old>rekado: Seems good to me.

<old>Btw thinking about this rn, but it would be great to be able to kill everything. Right now my workflow can take a few hours, but if there's something wrong, I have to kill every processes manually with htop

<old>Just catching Ctrl-C and prompting the user to confirm of killing every processes and terminating the workflow would be great

<old>I could make a patch for that if the idea is welcomed

<rekado>yes, sounds good

<rekado>but I think it should be confirmed .

<rekado>could be terribly frustrating to accidentally hit Ctrl-C and have all jobs terminated

<rekado>e.g. receive SIGTERM two times to terminate all jobs; or use a different signal all together.

<old>Which is why it should prompt for confirmation

<old>> You're about to terminate prematurely your workflow. Continue? [y/N]

<rekado>I wonder if that’s bad style.

<old>how about this:

<rekado>SIGTERM should definitely kill GWL

<rekado>but I don’t know about kiilling all launched jobs

<old>It should. There's no point in having processes to continue imo

<rekado>it would be a good default, I agree.

<rekado>does it make sense to add an option to keep launched processes running?

<rekado>--show-mercy ;)

<old>So SIGTERM to terminate evertyhing. But we could make it a command line option like `--prompt-to-kill` so that if you're debugging your workflow, you can simple hit `Ctrl+C` then `yes` to stop it

<old>yes it could be a case

<rekado>I think Ctrl-C should never be interactive.

*rekado will be back later

<old>Well then an option like `--kill-on-interrupt` or something similar. The SIGTERM is good but also painful for when you're debugging

<old>But just having the improvement of killing GWL should kill subprocesses would be a big thing on its own

<old>Oh oh what about this one. `--terminate-on-signal=SIGINT`. By default it would be `SIGTERM`.

IRC channel logs

2022-10-04.log