GNU bug report logs - #60408
[PATCH wip] guix: Support showing status in parallel.

Previous Next

To reply to this bug, email your comments to 60408 AT debbugs.gnu.org.

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

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

From: Julien Lepiller <julien <at> lepiller.eu>
To: guix-patches <at> gnu.org
Subject: [PATCH wip] guix: Support showing status in parallel.
Date: Thu, 29 Dec 2022 19:42:12 +0100

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

Hi Guix!

The attached patch allows showing more detailed status in parallel.
One of the reasons for doing that is for supporting another of my
patches, that allows specifying download tasks and build tasks numbers
separately, with a default of 1 for each (so 2 tasks in parallel by
default).

With verbosity level 2, all messages from all builds are shown
(interleaved, obviously), and messages for other levels are the same.

When only one build is performed, no changes are visible.

When multiple builds are happening in parallel, this patch shows one
line per running job (whether build or download), and messages above.
This will look like this:

module-import-compiled.drv  75% ▕█████████████████████████            ▏
openjdk-9.181-jdk  337.6MiB 4.3MiB/s 00:07 ▕█▌                ▏   8.8%


If there is no progress lines in the output of a build, it doesn't show
a spinner (yet), so no feedback that something is happening, but that's
planned for v2. One other issue is probably caused by having lots of
events (caused by build log output), that make status lines blink.
Another issue is when you ^C, the cursor is on the first status line.

My ideas for this patch are:

First, it's possible to go back a few lines with an ANSI escape code,
so basically print all status lines, then go back to the first line.

When an even needs to print a new line, let it do it from the first
status line, and print the status lines from below it.

Sometimes, an event will contain an incomplete line (for instance, it
ends with \r instead of \n), so I want to record the line to prevent it
from being overwritten by a status line. It's printed together with the
status lines, so we can go back to that line and print the rest of the
line when we get more of it.


Thoughts, ideas?

[0001-guix-Support-showing-status-in-parallel.patch (text/x-patch, attachment)]

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: guix-devel <guix-devel <at> gnu.org>, 60408 <at> debbugs.gnu.org
Subject: Re: bug#60408: [PATCH wip] guix: Support showing status in parallel.
Date: Tue, 21 Mar 2023 10:40:09 -0400

Hi Julien,

Julien Lepiller <julien <at> lepiller.eu> writes:

> Hi Guix!
>
> The attached patch allows showing more detailed status in parallel.
> One of the reasons for doing that is for supporting another of my
> patches, that allows specifying download tasks and build tasks numbers
> separately, with a default of 1 for each (so 2 tasks in parallel by
> default).
>
> With verbosity level 2, all messages from all builds are shown
> (interleaved, obviously), and messages for other levels are the same.
>
> When only one build is performed, no changes are visible.
>
> When multiple builds are happening in parallel, this patch shows one
> line per running job (whether build or download), and messages above.
> This will look like this:
>
> module-import-compiled.drv  75% ▕█████████████████████████            ▏
> openjdk-9.181-jdk  337.6MiB 4.3MiB/s 00:07 ▕█▌                ▏   8.8%
>
>
> If there is no progress lines in the output of a build, it doesn't show
> a spinner (yet), so no feedback that something is happening, but that's
> planned for v2. One other issue is probably caused by having lots of
> events (caused by build log output), that make status lines blink.
> Another issue is when you ^C, the cursor is on the first status line.
>
> My ideas for this patch are:
>
> First, it's possible to go back a few lines with an ANSI escape code,
> so basically print all status lines, then go back to the first line.
>
> When an even needs to print a new line, let it do it from the first
> status line, and print the status lines from below it.
>
> Sometimes, an event will contain an incomplete line (for instance, it
> ends with \r instead of \n), so I want to record the line to prevent it
> from being overwritten by a status line. It's printed together with the
> status lines, so we can go back to that line and print the rest of the
> line when we get more of it.
>
>
> Thoughts, ideas?

This looks like a welcome improvement to our user interface, if the
kinks can be ironed out!  Currently, as you've noted, it wobbles way too
much (due to the high refresh rate?), and there appear to be some
oddities sometimes (a configure script checking... line was preserved as
a build for a bit).  I think some other project is doing this kind of
fancy terminal multiplexing, but I forgot which one.  It'd be nice to
see what they are doing and what library they use to do so.

I don't know what others think, so I'm CCing guix-devel to open out the
discussion a bit.

-- 
Thanks,
Maxim

Previous Next

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