upgrading/installing in a background process

[René J.V. Bertin]

On Tuesday May 05 2015 15:35:17 Clemens Lang wrote:

>Fix one of the occurrences of flush, and MacPorts will fail on the next. Even

There's only 1 flush in MacPorts tcl code, and most in the tcl libs are actually commented out.
You were not claiming that the next invocation of the same flush command will fail, were you?

>started the command and gets closed later on you will get the same problem. Did
>you even test this change?

Yes. And it works as expected. Evidently, I'd say.

> Since the workarounds for this are trivial

Yeah, my patch is exactly that ^^

>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.

I don't argue with that, but the delay I'm referring to is quite annoying if you planned to start a really/truly long operation in a batch-like mode and realise there are trivial issues holding it up, each requiring negligible time to address (compared to the delay).

>That's because it executes a *lot* of Portfiles. Flushing stdout has nothing to do
>with it. Please, remember Knuth:

Probably, remember I wrote "*could*". When I use the -d flag I see that lots of output is being generated which normally would go to the log (or so I presume) during the delay, but I also didn't think it worth the effort to figure out how to do an isatty in tcl and see what difference it'd make. Yet :)

What I don't know is how much overhead the catch statement adds to the flush, but apparently it's not called as often as I feared.

>  "We should forget about small efficiencies, say about 97% of the time: premature
>   optimization is the root of all evil."

Well, I'm not a computer scientiest so I remember Knuth only as the father of TeX and not of anything realtime or supposedly interactive. That kind of approach is too similar to "ifs are expensive" or "don't bother with optimisation; new hardware is cheaper and faster" to my taste. In my book, small inefficiencies are the sort of thing you avoid while typing in your code because it takes a negligible amount of overhead.

R