all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: John Soo <jsoo1@asu.edu>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: guix-devel@gnu.org
Subject: Re: RFC: subcommand to pause/resume builds
Date: Tue, 03 Nov 2020 09:12:10 -0800	[thread overview]
Message-ID: <874km6z7o5.fsf@asu.edu> (raw)
In-Reply-To: <87ft5q4d0i.fsf@nckx> (Tobias Geerinckx-Rice's message of "Tue, 03 Nov 2020 17:32:29 +0100")

Hello Tobias :),

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Ludo',
>
> Ludovic Courtès 写道:
>> First, note that the daemon is unaware of “packages”, it only knows
>> about “derivations”.
>
> Derivations have a (file) name, which can be matched with a regex
> allowing one to, say, ‘pause libreoffice’.  It works in practice.
> I do this often & it's *extremely* convenient.

This feels close to little sed/awk pipelines.  Which is not to be
entirely dismissive. I like the compositionality of these tools.  In
fact I mentioned earlier that it might be good to send arbitrary
signals. But why not let kill (shell or scheme) do that?  All we would
need is to filter and format pids in a composable way (on the scheme
side and the shell side). That has the benefits of remaining agnostic on
side effects in builds (let the user decide what they are comfortable
with) and being more composable.

Maybe flags like this would be enough:

guix processes --session=<derivation-regex> ...

to get something like

5555
1212
343434
...

> Sometimes even necessary, because I have a habit of starting too many
> builds ;-)  It's nice not to lose 6h of work.

Indeed. This already saved me hours after learning it yesterday.

> Not every handy hack needs to be upstreamed though.  ‘It's fugly’ is a
> strong argument in Guixland, and I like that.

Same.

> T G-R, now thinking about acronyms like ‘CRIU’ and what a next-level
> hack would look like...

Yeah seems like functional build systems would ideally be
order-independent, pause/resumable, and the build steps time-travelable
themselves. But that's a cool aside for now.

Thanks for the tips!

John


  reply	other threads:[~2020-11-03 17:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 18:56 RFC: subcommand to pause/resume builds John Soo
2020-11-03 13:53 ` Ludovic Courtès
2020-11-03 14:41   ` John Soo
2020-11-03 16:32   ` Tobias Geerinckx-Rice
2020-11-03 17:12     ` John Soo [this message]
2020-11-06  8:56       ` Ludovic Courtès
2020-11-03 17:19     ` Tobias Geerinckx-Rice
2020-11-03 18:27       ` John Soo
2020-11-03 20:01       ` John Soo
2020-11-06  8:58         ` Ludovic Courtès
2020-11-06 23:00           ` John Soo
2020-11-04 10:28   ` Bengt Richter
2020-11-06 21:11   ` Mark H Weaver
2020-11-08 16:30     ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2020-11-05  4:37 John Soo

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874km6z7o5.fsf@asu.edu \
    --to=jsoo1@asu.edu \
    --cc=guix-devel@gnu.org \
    --cc=me@tobias.gr \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.