keep spinning even without new line

keep spinning even without new line

[Ricardo Wurmus]

Hi Guix,

when using “guix package -i” the build log lines are replaced with a
spinner character.  In some cases, the build log does not produce new
lines for a long time, so that the spinner appears to be stuck.

What do you think of advancing the spinner even when the build log is
not verbose enough to trigger the display of the next character?  How
can this be accomplished?

-- 
Ricardo

Re: keep spinning even without new line

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Guix,
>
> when using “guix package -i” the build log lines are replaced with a
> spinner character.  In some cases, the build log does not produce new
> lines for a long time, so that the spinner appears to be stuck.
>
> What do you think of advancing the spinner even when the build log is
> not verbose enough to trigger the display of the next character?  How
> can this be accomplished?

One way to accomplish this is to generate periodic “(build-log
heartbeat)” events, so that “print-build-event” in (guix status) only
needs to advance the spinner when the last event was a build-log event.

Currently, events are produced only by “build-event-output-port”, which
generates them when processing build trace strings sent by the daemon.
I don’t really want to change the daemon to intersperse the actual build
output with heartbeat traces, so maybe a timer should generate these
events in “build-event-output-port” or even earlier in “process-stderr”.

“process-stderr” is probably too low-level, and there’s a chance that
injecting output there would corrupt the output sent by the daemon.

Any better ideas?

--
Ricardo

Re: keep spinning even without new line

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On 2018-12-29, Ricardo Wurmus wrote:
> when using “guix package -i” the build log lines are replaced with a
> spinner character.  In some cases, the build log does not produce new
> lines for a long time, so that the spinner appears to be stuck.

> What do you think of advancing the spinner even when the build log is
> not verbose enough to trigger the display of the next character?  How
> can this be accomplished?

Are you proposing that the spinner spins even when there's no indication
that anything is actually happening? Or is there some source of
information other than the build log output?

It could spin multiple times for each line, and space them out over
time... (multiple lines in the same time-window might only spin X number
of times)

To me, it would make sense that the spinner should stop spinning if the
build is stuck or just not very active... otherwise, it's not providing
useful information to the person watching...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: keep spinning even without new line

[Ricardo Wurmus]

Hi Vagrant,

> On 2018-12-29, Ricardo Wurmus wrote:
>> when using “guix package -i” the build log lines are replaced with a
>> spinner character.  In some cases, the build log does not produce new
>> lines for a long time, so that the spinner appears to be stuck.
>
>> What do you think of advancing the spinner even when the build log is
>> not verbose enough to trigger the display of the next character?  How
>> can this be accomplished?
>
> Are you proposing that the spinner spins even when there's no indication
> that anything is actually happening? Or is there some source of
> information other than the build log output?

The build log is all we’ve got.  I do propose to spin even when no new
line has been produced.

> To me, it would make sense that the spinner should stop spinning if the
> build is stuck or just not very active... otherwise, it's not providing
> useful information to the person watching...

It is providing useful information, namely that Guix itself is still
running and not stuck.  It shows that the build is still going on, even
if the build consisted of “sleep 100000” statements :)

Guix eventually aborts the build after a certain amount of silence.
Since the last line that is printed and the timeout all a user of “guix
package -i” sees is a stuck spinner; a user of “guix build” will at
least see the last lines of build output and can guess what this means
for expected delays.

My goal is to provide assurances to the user of “guix package -i” that
Guix is not “stuck”, to remove the doubt that a long uncommunicative
build can bring.  (People who want to know details would increase
verbosity anyway.)  Spinning while Guix is waiting for build output from
the daemon seems like a good way to accomplish that to me.

--
Ricardo

Re: keep spinning even without new line

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Guix,
>>
>> when using “guix package -i” the build log lines are replaced with a
>> spinner character.  In some cases, the build log does not produce new
>> lines for a long time, so that the spinner appears to be stuck.
>>
>> What do you think of advancing the spinner even when the build log is
>> not verbose enough to trigger the display of the next character?  How
>> can this be accomplished?
>
> One way to accomplish this is to generate periodic “(build-log
> heartbeat)” events, so that “print-build-event” in (guix status) only
> needs to advance the spinner when the last event was a build-log event.
>
> Currently, events are produced only by “build-event-output-port”, which
> generates them when processing build trace strings sent by the daemon.
> I don’t really want to change the daemon to intersperse the actual build
> output with heartbeat traces, so maybe a timer should generate these
> events in “build-event-output-port” or even earlier in “process-stderr”.
>
> “process-stderr” is probably too low-level, and there’s a chance that
> injecting output there would corrupt the output sent by the daemon.

I wonder if we could use Guile 2.2’s suspendable ports to deal with this
case (info "(guile) Non-Blocking I/O").  To avoid global effects, I
think we could explicitly use the (ice-9 suspendable-ports) procedures
in ‘process-stderr’ and the caller in (guix status) maybe would set a
‘current-read-waiter’.

Thoughts?

Ludo’.