----- On 5 May, 2015, at 14:33, René J.V. Bertin [email protected] wrote:
> I think there's really no reason to allow the flush command to abort in this > case. The alternative would be to do the tcl equivalent of > `if( isatty(stdout) )` because the flush probably makes sense only when stdout > is connected to a terminal ... Fix one of the occurrences of flush, and MacPorts will fail on the next. Even adding isatty(stdout) won't change a thing in your "use case": We already check for stdout being a TTY for the progress bar code, but if it was a TTY when you started the command and gets closed later on you will get the same problem. Did you even test this change? In the end, running MacPorts without a connected output channel is currently not supported. Since the workarounds for this are trivial, I won't invest any time to make it supported. > How often is this flush executed, and what percentage of the corresponding > progress indication is never sent to a terminal? It's executed once per dot printed during dependency calculation. As you can see from the code, the flush is necessary because the dot would otherwise not be visible on a users terminal until the process was complete. All of the progress indication is sent to a terminal, unless you do not have a terminal attached to MacPorts' stdout (which is not a very common use case). In most cases where MacPorts' stdout is not a terminal, it still exists (e.g. a file or just /dev/null), in which case the flush is superfluous, but harmless, especially when compared to the compile times of some of our ports. > Flushing can be expensive (very, even), and *could* be part of what delays > build/upgrade commands for ports that have a lot of dependencies (the VM in > question takes almost a minute to check all dependencies of > port:kde4-workspace > before it starts fetching/extracting/patching/etc). That's because it executes a *lot* of Portfiles. Flushing stdout has nothing to do with it. Please, remember Knuth: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Clemens Lang _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
