Thinking about messages

[mattwarkentin]

Hi @wlandau,

I was wondering what you think about modifying the standard message queue produced by tar_make()/tar_make_*() to make it more obvious when a target is built. In the case of running things sequentially with tar_make(), sure, it's implied that when the next target starts, the previous one must have finished.

But in the parallel setting, when you have many targets being built concurrently, taking different lengths of time, it's fairly difficult to tell from the message queue which targets have finished because you really only know if they started. Essentially, when the number of targets started exceeds the number of workers, you can no longer easily tell which targets are running or have been built from the queue (unless you run tar_progress() in another session). Basically I'm wondering if the types of informative messages in the standard message queue could be brought closer to the statuses presented by tar_progress().

In other words, during a call to tar_make() et al., a target can go through a lifecycle of:

1. skipped, if up to date

or

2. started - and if started, it either gets built, cancelled, or errors. If the target errors or is cancelled, those messages do get shown in the queue (as below).

● run target foo
x error target foo
● end pipeline

● run target foo
● cancel target foo
● end pipeline

So only if the target gets successfully built do you not really get any other feedback (except ● end pipeline, which I admit was a very nice addition to the message queue). But I keep wanting something like:

● run target foo
✓ built target foo
● end pipeline

What are your thoughts?

EDIT: Another good reason to add the "built" messages, I think, is that for those of us that use reporter = "timestamp", you'll actually be able to tell how long a target took to build (roughly) from the message queue alone.

[mattwarkentin]

While I'm being ultra pedantic about messages:

• Should ● end pipeline be a tick, like skip pipeline? This probably makes sense if you consider adding the built messages described above, since the pipeline ending is sort of a successful end event, not the start of something.

✓ end pipeline
✓ skip pipeline

• Since {crayon} isn't enabled in the build pane and other non-interactive sessions, should there be different icons for each status, to make the messages more distinct?

▶ run target foo
or
● run target foo

x error target foo
■ cancel target foo
✓ built target foo

All symbols taken from {cli} package.

[wlandau]

I like your first suggestion and implemented it in 25b4280. (I have been thinking more about logging and progress lately. tar_poll() is a new one, and tar_watch() has some improvements.)

I tried multiple symbols in drake, but some of the funnier ones do not render well on different machines. I would like to stick with dots, checks, and crosses: dots when some work was done, checks when some work was skipped, and crosses for errors only.

[mattwarkentin]

Is there a reason for using "run" and "end" instead of "start" and "built", as the functions/status suggest?

Also, not sure if it is related to this most recent commit, but the spinner seems to have disappeared when I installed the dev version just now (spinner for tar_watch() is fine, but not for tar_validate() et al.). Not sure if this is a "me" problem.

I tried multiple symbols in drake, but some of the funnier ones do not render well on different machines. I would like to stick with dots, checks, and crosses: dots when some work was done, checks when some work was skipped, and crosses for errors only.

Fair enough!

[wlandau]

Is there a reason for using "run" and "end" instead of "start" and "built", as the functions/status suggest?

You are right, those terms are clearer and more consistent.

Also, not sure if it is related to this most recent commit, but the spinner seems to have disappeared when I installed the dev version just now (spinner for tar_watch() is fine, but not for tar_validate() et al.). Not sure if this is a "me" problem.

I removed the shinycssloaders spinner to fix #386. There should be a less obtrusive shinybusy spinner in the upper left.

[mattwarkentin]

I removed the shinycssloaders spinner to fix #386. There should be a less obtrusive shinybusy spinner in the upper left.

Sorry, I meant the spinner that shows up in the R console when calling most functions, like tar_make() and tar_validate(). They aren't showing up for me with the dev version. But again, this might just be something funky on my end.

[wlandau]

That was in response to #364. Just brought back the spinner for non-summary reporters (0c8de5c).