[MPlayer-dev-eng] [PATCH] clean up tests in configure

Diego Biurrun diego at biurrun.de
Tue Jul 5 02:42:15 CEST 2005


On Mon, Jul 04, 2005 at 10:30:42PM +0300, Ivan Kalvachev wrote:
> On 7/4/05, Diego Biurrun <diego at biurrun.de> wrote:
> > > I think this is enough reason to reject the patch.
> > 
> > I disagree unless you can come up with a case where this might fail in
> > practise and not just in theory.
> > 
> > > As for the rest of 'cleanups' I think that they could be trown away in
> > > favor of the proposed change from () to {} . {faster speed while more
> > > readable}.
> > 
> > I think the other changes apart from -a/-o and uncontroversial so I'll
> > apply these anyway.

typo: s/and/are/


> And I will revert it.
> This patch doesn't do anything else than obfiscation.
> 
> DonDiego don't boss around you are not the MPlayer team.
> These kind of things cannot be desided only by you and you are not the
> one that have the finnal word.

The same applies to you so please don't start flaming.

I surely wasn't trying to "boss around" anybody and I don't think I did.
Maybe I was just unclear, so I'll try to find better words now:

-a/-o vs &&/||:
===============

You say that

1) -a/-o is less readable (even "obfuscated"),
2) the possibility for ambiguity with -a/-o is reason enough to reject
   the patch.

I disagree on both counts since

1a) -a/-o is shorter (and IMO this aids readability on long lines),
1b) -a/-o avoids another test invocation and should thus be faster,
1c) after a short time of getting used to it -a/-o should be equally
    readable for everyone.
2) I don't think we run the risk of ever hitting that ambiguity and
   1a-c) might be a real gain in practise.

Speed will have to be measured.  We might be talking about unnoticeable
gains or even nothing at all.  Then again it might be real.

subshells etc:
==============

The patch in question consists of basically two parts

a) &&/|| --> -a/-o
b) removing subshells and other small speedups/simplifications
My understanding was that only a) was controversial and thus I wanted to
commit b) alone.  I think at this point nobody is 100% certain what b)
really consists of, so I'll split it off and propose it separately.
We'll see whether or not it is problematic then.

Diego




More information about the MPlayer-dev-eng mailing list