Not sure what work you are referring to. Here’s a clarification of what happens if you pass --color off:
Node.start() and Node.end() will be reduced to a single, trivially-predicted branch that discovers .index == .none and then returns from the function doing nothing.Thanks for the clarification! Looking at the diff, it’s absolutely non-trivial; heck you even wrote that it was challenging and intense. From a cursory glance, it’s hard to find what work is being done if .disable_printing is true - hence “AFAIUI”. Given the naming, I had assumed there’s still communication setup and a back and forth across the pipe, yet the output would be suppressed.
For me personally, this is a hectic output that’s catching attention but impossible to follow. The Y axis hops around wildly, and I find myself reading random things across the screen which give me no idea of “progress”. Turning it off with “--color off” is a temporary switch name / overload decision, I suppose, as I’d never expect “color” to control “output amount”.
Not sure why you named this “progress bar” as well: ISTM more like a “--verbose”, and I fail to understand its added value in terms of UX. I’m certain you’re convinced there is - else you wouldn’t do something that’s as intense and needs you to be at the top of your game, etc. Is this your preparatory work for implementing an actual progress bar?
A tree view is a more accurate representation of the state of the process than a linear percentage. I’m not sure why you think the next step would be replacing such a rich display with one that would freeze & jump around like the infamous Windows file copy dialog.
The purpose of such a user interface element is to communicate the state of the software to the user and give them a sense of progress. It’s not to provide a record of what the software has done, which is available via other flags such as --summary all when using the build system, or --verbose as you mentioned, which already exists.
To be honest, I don’t sympathize with you finding it impossible to follow. In practice, the root node stays active for the majority of the duration of the process, and it no longer rapidly switches between subprocesses fighting over the same line. It’s objectively better than before. Similar to learning how to use version control, if you spend time learning how to take in this information, you will gain the ability to use a new tool to learn insights during the software development process that you would otherwise not be privy to. If you choose not to learn this skill, that’s fine, but others will pass you up and move on to greater heights.
Even the “rich” display freezes and jumps around naturally, because the nodes in the progress don’t take equal amounts of time. Look at the “LLD Link” line for example in comparison to others.
You called it progress bar, hence me asking if the next step is doing the actual bar.
The first line, as you point out, better captures the progress. It just takes concentration to ignore the changing parts of the screen which contain throwaway information (which get removed as they’re done, so you as the artist seem to agree that it’s not worthwhile looking at after the fact, as you delete it again). I don’t understand why you increase the necessary processing power to parse this. This is why I think the next step would be replacing such a “rich” display with one that reduces the information to its core.
We as humans have evolved to focus on visual changes. If the root node is objectively better (I agree) the flurry of changes is objectively worse (due to human nature, reading speed, and general attention direction - at least that would be my argument). You’re aiming at improving the compiler speed more and more - this progress tree output with all the details of what’s going on is supposed to become quicker and quicker, and less readable / digestable over time if you are achieving your goals. If you’re ultimately successful, in the end, you might as well not output it at all.
I find it hard to believe that others will pass me up and move on to greater heights due to them looking more intently on ephemeral screen content, but maybe there’s a deeper mental training to be had from working on oneself to consume more transient information. I will spend some time considering this possibility (and others, if they come to mind), but this is crossing over into my personal development, not zig’s. Thank you for sharing your thoughts, these are mine FWIW.
Aside from the fact that this is much more informative, the tree visual is just really cool to look at. I also find the build process much more enjoyable when you see progress in real time like this.
Congrats!
you can mimic this in linux too that would allow both implementations to be very similar: pipe, fork, in child blocking read on the pipe, parent write after finishing setup for child, child execs. basically using the pipe as a semaphore to let the parent tell it when it was okay to exec the child image.
can’t we just enjoy nice things, like I get your point, but can’t we just agree that it looks cool, and that it’s an improvement over what we had ? If so, then we should just enjoy it and be thankful someone decided it was important enough to dedicate probably a lot of time figuring out how to do it while only consuming 1% more ressources. In fact I find it so cool that sometimes I delete the zig-cache, and the zig-out just to see it again lol.
If you get the point I was trying to make, you’d understand that it’s not “nice”, “looks cool”, and “is an improvement”, quite the opposite.
As the person having tried (and - obviously - failed) making the point, I can tell you, respectfully, you didn’t get it.
It seems it was fun for andrew to make, and it seems it’s fun for you to consume. That’s great. I can turn it off. That’s great. I think we can leave it at that.
To be clear, my primary motivation for working on it was not “fun”. The fun comes from my positive attitude while wrangling shitty POSIX APIs.
Neither was the motivation for users of Zig to have fun. The fun of using Zig happens when you have an excellent tool and you get the satisfaction of tackling a hard problem, and delivering good results to your users.
My primary motivation was to make a better implementation of CLI progress. That objective has clearly been accomplished. Users of Zig now have a better insight into concurrent pipelines. That includes Zig compiler authors as well, and as mentioned in the post this better insight already lead to a subtle bug fix. It’s also highlighting other parts in our pipeline that could be improved.
I think if you tried to argue why the old implementation is better than the new one you would quickly contradict yourself. I haven’t seen you attempt to do that in this thread.
Is there maybe a more traditional output (as if make or gtest was run – a simple scrolling one line per action) for build and test runs for Ci/CD pipelines that is possible to turn on? That might be more @msw style and make both sides happy.
$ zig build --help
...
--verbose Print commands before executing them
...
Hey all, there may be a bug or limitation of the Progress/Progress.Node objects with respect to testing. I left a more detailed description in this ticket:
Please let me know if there is an alternative pattern or architecture I should use or if this is a valid use case that should be supported.
Thank you!