macports with closed stdout

[Clemens Lang]

Hi,

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

> I don't see how those flushes would influence the one flush that gave me
> problems and that I protected in a catch?

They don't, but they will fail equally in the situation you describe.


> 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 flush commands in src/port/port.tcl *are* executed during port upgrade, so
they would also cause problems. They may not abort the build because the code
paths that call the progress callbacks deal with errors in these callbacks, but
you would at least get uncommon error messages in your log file, and potentially
lots of them.


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

Well, in this case -v disabled the progress bars and thus this code path. Since
-v is not the default I would expect a comprehensive test to also test this,
which you did not, or you would have seen the broken progress bars.


> The delay issue is side-ways related to the flushing issue.

Well, as I said, the delay isn't caused by the flush.


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

MacPorts isn't built to do incremental builds and this is unsupported. Nobody
can stop you from using it in this way, but don't be surprised when people do
not understand what your problem is or why it is a problem. If you don't want
the dependency calculation to happen, don't use MacPorts but build from source
on your own.


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

If it could, we would do that. Unfortunately, it cannot. Look for the recent
threads on this year's SAT-solving project for GSoC, which will explain some of
the problems.


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

That sounds like a perfect use case for screen or tmux.


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

Yes, and then somebody came along and implemented a similar set of requirements
in screen and tmux, and the world has been using those ever since.


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

A procedure creates a coupling between the modules that use it. If you wrote a
wrapper for flush that wraps it in catch, where should you put it from a software
design point of view? If it's used from both macports1.0 and port.tcl, there's
no good place in the MacPorts source tree to put it, because we want to keep
dependencies between these two modules small.

-- 
Clemens Lang