[PATCH wip] guix: Support showing status in parallel.

  • Open
  • quality assurance status badge
Details
2 participants
  • Julien Lepiller
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Julien Lepiller
Severity
normal
J
J
Julien Lepiller wrote on 29 Dec 2022 19:42
(address . guix-patches@gnu.org)
20221229194212.44e5cabf@tachikoma.lepiller.eu
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?
M
M
Maxim Cournoyer wrote on 21 Mar 2023 15:40
(name . Julien Lepiller)(address . julien@lepiller.eu)
87r0tip3qu.fsf@gmail.com
Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (44 lines)
> 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
?