macports with closed stdout

[René J.V. Bertin]

On Tuesday May 05 2015 17:44:28 Clemens Lang 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

Sorry, I did `grep 'flush.*std' -R /opt/local/libexec/macports --include="*.tcl"` to catch explicit flushing of std{in,out,err}

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

I don't see how those flushes would influence the one flush that gave me problems and that I protected in a catch?
As far as I've been able to tell, it really hinges on a single flush (1 invocation of 1 flush expression). It's not impossible that other flush calls will fail during commands other than `port upgrade`, but it doesn't seem very likely.

>the same way. You may have passed flags that caused these code paths not to be
>executed, but that's not a comprehensive test.

No, I did nothing of the sort, at least not voluntarily. I just passed -vk in this case.

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

The delay issue is side-ways related to the flushing issue. It doesn't really apply when doing a bunch of updates or installs, but rather working on a single port. In this particular case, I was checking whether the current version of one of my ports would still build from scratch. On my own system I tend to do incremental builds, which sometimes means I end up with patchfiles that no longer apply correctly. If you're repeating the patch phase multiple times until all affected patchfiles have been corrected, having to wait almost a minute each time before the patch phase actually starts is annoying.

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

Ok. It was just a thought anyway.
I'm not sure I get why Portfiles are executed (parsed?) when checking if another port's dependencies are up to date: it seems that could be determined from the portindex files with much less overhead?

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

Actually, I *did* google how to do an isatty in tcl and saw it wasn't completely trivial. Good to know someone thought to provide a C implementation of it.

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

Normally, I'd do that. There are reasons in this case why I prefer not to, basically because I like to be able to monitor the process as long as possible. Also, my ssh connection to the VM tends to freeze if there's no activity for too long, which is something I prefer to avoid.

A couple of lives ago, during my PhD, I implemented a feature in my simulation software that allowed it to switch its tty output to file (and back again, as long as the terminal survived). There was more incentive for that kind of thing in an age where a regular run would take days, and more complex runs a week or more :)

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

Well, that's why procedures were invented, no? :)

Cheers,
R.