On Tuesday May 05 2015 19:58:44 Clemens Lang wrote:
>They don't, but they will fail equally in the situation you describe.
Then why didn't they? When I tested my patch, I closed the ssh connection
almost immediately after starting the upgrade (of 2 ports), so there should
have been ample occasion for these flushes to be called...
>paths that call the progress callbacks deal with errors in these callbacks, but
As they ought to. Progress indication is a convenience to the user that should
never interfere with the process it measures...
>you would at least get uncommon error messages in your log file, and
>potentially
>lots of them.
Well, that's hard to tell, because apparently the log is truncated when the
activation phase begins. I never noticed this before, but then I rarely check
the log after a successful install ...
>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.
Without a terminal to show them? :)
>That sounds like a perfect use case for screen or tmux.
I might check out tmux, but screen gets in my way by trying to be too clever.
The easiest would be to redirect all output (">&") to file and then use tail -f
until I decide to disconnect. Or maybe it'll be enough to pipe all output to
cat, or otherwise an application that redirects it output elsewhere if
stdout/stderr are closed (I think I must have something like that lying
around). More often than not all that interests me when reconnecting is if the
port command completed successfully, because if not there are logs already.
>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.
I'll pretend I haven't understood since the beginning of this exchange that
nothing will change and give a rhetorical answer to a rhetorical question ... :)
You'll have to compromise and chose which design principle is more important
(limiting interdependencies or avoiding code duplication in this case).
Or maybe it can go into the C source base (pextlib?). Or patch the dedicated
tclsh. Enough possibilities.
R
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
