BuildStream-Migration-Bot commented on issue #18: URL: https://github.com/apache/buildstream/issues/18#issuecomment-752406153
In GitLab by [[Gitlab user @tristanvb]](https://gitlab.com/tristanvb) on May 1, 2017, 12:27 So this is partly addressed, I'm not sure I'm happy with the layout but it's an improvement. Now the separator line between the rolling log and the task list shows the following centered in the `====` separator: * The main bst invocation target * The total elapsed time of the session Other information fit on that line, but the result was too cluttered to easily read at a glance, so the status area now has 3 lines as a header... example: ``` ... rolling log lines ... ===================================== 00:00:12 gedit.bst ===================================== [Session:4] [Total:6] [Fetched:4] [Built:0] ~~~~~ Active Tasks ~~~~~ ... active tasks displayed here ... ``` Again here, the extra centered separator takes a precious additional line, but without it the additional information looks cluttered and difficult to read. The additional information is element counts of: * `Total` The total number of elements in the pipeline * `Session` The number of elements which were queued in this session / invocation * Number of elements which have passed each scheduler queue, in this case: * Number of elements which have passed through the `fetch` queue * Number of elements which have passed through the `build` queue For the Queue monitors, they will display different information depending on the `bst` invocation, e.g. only `fetch` queue is used for `bst fetch`. After implementing the artifact cache sharing, a `bst build` invocation will also have a third `upload` queue for a client configured and authenticated for artifact uploads. This should mostly take care of ongoing status information but maybe could use some polish... ## Regarding Timestamps So here I'm not entirely sure that I agree with *"having elapsed time in every line of the log is useful"*, as in, I'm mostly interested to know how much time it took for a given task to complete, while the information of *"the offset time in the session whence the task began"* seems not to be of much value or relevance. Now, it is also a goal to have presentable log lines, which means either: * Making a best effort to ensure the lines fit within 80 characters *(what we currently do)* * Perhaps intelligently wrapping the last (dynamic length) portion of the log lines so that they do not wrap all the way around the terminal, but instead wrap at the column where the dynamic length "short message" began, would be a nice improvement. This is a bit difficult to reason around though since it's also a problem that elements themselves can have overly long names which dont fit into the 30 or 40 char padding we currently try to align them into, it would be best to have reliably columnized log lines at least when viewed in the terminal for better readability, maybe this can be done with an ellipsis (`...`) of the *leading* chars for overly long element names (filenames). With that added emphasis on how important I think presentation of output should be out of the way, this is the conundrum I have about adding *"session offset timestamps"* to each and every line: * I care a lot about knowing how long it took a given task to complete * I'm not sure what the relevance is for offsets in time, except perhaps in a case that we did not have a status area at all, in which case it tells the user generally how long this has been taking so far * If we were to have both, *even* if we only showed task/activity elapsed time in lines where a task completes, it *still* takes an extra column for those lines; which means we bust the 80 chars target in log lines more often, which is undesirable If the *"session offset timestamps"* are that desirable, an alternative would be only output those to the target log file (i.e. `bst --log-file <filename> ...`), or to additionally only output those when the terminal width is at a given threshold, maybe at 100 or 120 chars wide. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
