[MPlayer-dev-eng] Re: [PATCH] Development (Was: Clean up

[Arpi]

Hi,

> > > I see. Didn't realise that it can be negative also. Why's that BTW?
> > why not? RTFS.
> 
> I didn't stumble over anything that made it negative so far. And I would
> really like to RTFS if it was readable (read: not so buttugly in big
> parts)

it IS readable. for the author of the code.

> > what's the problem with this? it is not my code, anyway it looks ok for me
> .
> 
> Spaghetti code. Easy to get it wrong, hard to read.

descriptive answer...

> > > So you have troubles using development tools? Say it so and I might be
> > > able to live with that. Otherwise this is simply FUD.
>  
> > why?
> 
> Because it's not the slightest problem to merge changes if you're used
> to CVS. Even better with bitkeeper.
i didn't said it's impossible just extra work to get through the merged file
and manually rename variables to get rid patch's fails.
if there would be at least one positives, but none.

> > you seems to be a tipical 'doesn't matter if it won't work or slower,
> > or breaks compatibility, but the source looks nicer' programmer (not coder
> ).
> 
> Sure. Guess what: The main reason for rewritting the select spaghetti
> code was that the demuxer actually showed in up in the upper half of
> my profiles which made me curious. Now while it isn't the optimal

anyway your profiles were bad. mplayer calls demuxer functions a lot
_before_ the actual playback starts. in playback loop it's called just a few
times per second, so your "fix" won't speed up playback at all.

anyway gprof and other profilers can't show this difference...

anyway 2: gcc and other c compilers compile switch {...} to function pointer
array and indexes in it at the pace of your switch(). so i can't see why
is your version faster?

> solution as you've pointed out it's already a lot faster and what's more
> important: CLEAN.
why is it cleaner? i can't see it cleaner. maybe cleaner fo ryou as it's
maybe closer to your programming style. but it doesn't mean cleaner, and it
mean less "cleaner" for us.

> I will probably do a bit more there since I might need the stuff for a
> future project. I'll toss in the patches, what you do with them is your
> problem.
feel free ... to send it to /dev/null
again: cosmetics is not welcomed here.
fork if you want to do cosmetics.

if you have patch which improves functionality (and doens't break anything)
but doens't do cosmetics (i can't imagine it from you anyway) it may be applied.

sorry if being rude, but i see from yoru first mail that you will never send
any usefull lines of contribution. yo ureminds me to someone who ran html
docs through some html tidy program and send us big patch...

the base policy of mplayer coding style: every developer has its own coding
style and he can freely use it in his code. contributors have to accept this
and send patches keeping the style of file contributing to.
just imagine what would happen if everyone starts to chaneg style of code...
then it would keep changing all time which breaks all diffs and make it more
difficult to read by its maintainer/author.
the other way is forcing a given indenting/coding style and force everyone
to use that. but no one will like this...


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu