monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Release time - au stdio update


From: Stephen Leake
Subject: Re: [Monotone-devel] Release time - au stdio update
Date: Thu, 27 May 2010 06:56:46 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

Thomas Keller <address@hidden> writes:

> Am 27.05.2010 10:22, schrieb CooSoft Support:
>>    Sounds like a great idea to me, especially the 1.0 bit :-)).
>> 
>>    However one minor point about the impending release (what ever
>> version it may be) :-(...
>> 
>>    I was looking at the changes for the next release and noticed the au
>> update command. Great, but why does it's progress messages go out on
>> stderr, should that not go out on stdout in the normal output stream
>> (possibly in stanza format)? 

First, a little background, just so we are all on the same page.

As of mtn 0.46, 'au stdio' has 5 output streams, plus a termination
message:

m   main structured output

e   unstructured error messages

w   unstructured warning messages

p   unstructured progress messages

t   ticker

l   termination message, including status of success or error.

The message macros E, W, P direct the output to the appropriate stdio
stream.

The progress messages from 'au stdio update' are in the progress stream, as
expected. 

Implementing 'au update' also allows calling 'update' from higher-level
user Lua commands, which don't care about parsing the output; see my
email thread on 'gds_update_all'.

>> It would be nice if it were consistent with other au stdio commands
>> as most things using au stdio treat output on stderr as indicating a
>> problem.

If you run 'mtn au update', _not_ using stdio, then the progress
messages show up on stderr. I don't think there is anything I can do
about that, except to say "don't do that".

Well, I _could_ rewrite all of the 'update' code, putting 'if stdio' all
over the place. But that's bad design; the current use of the P macro is
much more elegant.

There is no reason to run "mtn au update" instead of "mtn update"; there
is also no difference in the interpretation of the messages on stderr.

There is significant reason to run update as part of a long-running "mtn
au stdio" session; it's more efficient than starting mtn several times,
and it allows separating progress from error messages.

There is significant reason to run update from high-level user Lua
commands; that requires that 'update' be an automate command.

Other automate commands don't use the progress stream yet, since it is
relatively new.

At the same time, other stdio commands are intended to return data, not
perform actions on the workspace. 'au update' is different in that
sense. I intend to implement more au workspace commands; it simplifies
the front-end design, and allows higher-level user Lua commands.

> Yes, this is indeed a bug. Stephe, could you please have a look at
> this?

I don't think this is a bug; I think it's a good example of 'au stdio'
streams, and an unfortunate side effect of the progress stream when not
using stdio.

The root problem is that standard processes have only two output
streams, instead of the five needed by sophisticated designs :).

The lesson here is that if you want to take full advantage of 'au
update', run it under 'au stdio', or from a user Lua command. Otherwise
just run 'mtn update'.

-- 
-- Stephe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]