macports with closed stdout

[Clemens Lang]

Hi,

----- On 5 May, 2015, at 16:24, René J.V. Bertin rjvbertin at gmail.com wrote:

> There's only 1 flush in MacPorts tcl code, and most in the tcl libs are actually
> commented out.

Wrong:

$> grep "flush " src/port/*.tcl | wc -l
      10


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

It certainly cannot work if all the flush commands in src/port/port.tcl fail in
the same way. You may have passed flags that caused these code paths not to be
executed, but that's not a comprehensive test.


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

You would have gotten the same situation if there was a trivial build failure in
one of the first few ports you installed. If what you really want is error handling
for MacPorts as a whole, why don't you do that then?

$> sudo port install foo; $send_yourself_a_mail "$?"


> Probably, remember I wrote "*could*".

Yes, and I've recently looked into this with profiling and I know the problem isn't
the output but executing the Portfiles. It is because of this knowledge that I
dismiss removing a flush as "premature optimization".


> 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 :)

See src/port/port.tcl, line 577: if {[isatty stdout]}
Implemented in src/pextlib1.0/tty.c.


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

Well, probably not a lot, but if you intend to disconnect from the terminal anyway,
why not just avoid the overhead (and the work) and just redirect the output to
/dev/null right away?


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

Wrapping every flush in a catch (and possibly every write operation as well?) is
non-negligible overhead for the programmer and quickly makes the code unreadable.
It may be a negligible runtime overhead, but that's not the only thing that
matters.

-- 
Clemens Lang