[PATCH V2] progress: add output-prefix for GUI clients

Jason Harris jason at jasonfharris.com
Sun Nov 6 19:35:39 CST 2011


On Nov 7, 2011, at 1:30 AM, Matt Mackall wrote:

> On Mon, 2011-11-07 at 00:06 +0100, Jason Harris wrote:
>>> Second, when the progress extension is not enabled, progress messages
>>> are generated in a fixed format on _stdout_, but only with --debug:
>>> 
>>> http://www.selenic.com/hg/file/afc02adf4ded/mercurial/ui.py#l683
>> 
>> Ahh... But then I am faced with the same problem which I / we use HGPLAIN to get
>> around in the first place. Authors may from time to time decide to print more or
>> less information when --debug is used.
> 
> Um... so? 

So... as I said this makes using --debug less robust for the GUI's.
Thus the GUI's won't use --debug. Simply as that... 

> I guess some people have not fully assimilated this concept (which
> should be read as a general guideline for programming and not as
> anything specific to internet protocols):
> 
> https://secure.wikimedia.org/wikipedia/en/wiki/Robustness_principle

Uh... I'll let the implied "I haven't assimilated this concept" slide...

The maxim that "be liberal in what you accept" has proven to be quite painful at
times. Eg the W3C tried to move away from this when they tried to move to eg
XHTML and stop accepting the hodge-podge of HTML messiness. In any case let's
not go down this philosophical discussion route...

But in any case HGPLAIN is *exactly* this kind of construct. It lets GUI writers
not have to handle lots of extra superfluous stuff...  Thus I am not to sure what the
philosophical objection is to allowing an option which can be used to do something
very similar.

You object to putting in a two line change which is totally orthogonal and self consistent
and yet you imply that GUI writers should fundamentally mess up their interface
code with all sorts of side checks and stuff, instead of changing the sending protocol by a couple of
lines to ensure integrity?? If I did that then I would likely add thousands of
lines to MacHg, with very very little to show for it.

Hmmm... Sorry but this just seems pretty one-sided...


> You should in fact always be prepared to get extra stuff you don't
> understand when communicating with another entity that's not under your
> control.

Well... That's the difference. It is under my control :)  I can change it
and have changed it... :)  Just not upstream...


> Especially in a 'verbose' protocol. We try hard to adhere to
> the 'conservative' side of this equation in normal operation, but that
> doesn't excuse fragility on the receiving end.
> 
> (I will grant that getting that achieving that robustness in
> environments/languages without convenient pattern-matching facilities is
> a pain.) 

Even in languages where this is possible it is a real pain...


>> Moreover this two line patch (for the progress extension) of adding the option
>> "output-prefix" is really simple and is completely independent of any of these
>> issues. It just adds a prefix to the output of the progress. All these other
>> details of how GUI writers use it has nothing to do with this patch whatsoever.
> 
> Granted, but you also have to admit it's a complete hack. It is really
> hard for me to look at this and think something other than "Jason is
> adding a wart to Mercurial to avoid adding a wart to MacHg" and that's
> exactly the sort of thing I'm going to push back on.

Well it's not a wart at all. It's not even a hack. It's just an option that
makes sense and is intelligible, and consistent, and self contained. Some people
might wonder what they would use that option for, but it's a clean change. (It just
happens to be incredibly useful for GUI clients... (not just MacHg))

> If you were instead
> adding a "progress channel" to the command server interface, I'd have a
> very different response.
> http://mercurial.selenic.com/wiki/CommandServer#Channels

That would of course be nicer. However, most of the current tools use the
historical interface (and due to multithreading reasons it will be hard to
transition to the command server (but I have it as a project to do one of these
days...))

So with the current interface you have stdin, stdout, stderr and that's it.
Should this progress stuff go on stdout? (No for the reasons I gave in the previous
email.) Thus they have to go on stderr. Is it reasonable to have a way to
reliably allow GUI writers to pick these progress bits out of stderr? I would
think so...

Thus I am sorry to say, that instead of adding at a guess a minimum of some 500
lines to MacHg and having a more unstable interface thought using --debug, and
having to introduce streaming machinery to parse the output as we get it, etc. I
think the 2 line fix to add a prefix to the progress information which is
completely self contained is the correct thing to do here. I try to send my
patches up stream and this is one of them. It makes doing the merge for new
versions easier... But if this doesn't fit for philosophical reasons then no
pasa nada, I'll just keep it in MacHg's version of mercurial. No harm no foul :)

Cheers,
   Jas


More information about the Mercurial-devel mailing list