[Mplayer-cvslog] CVS: main ChangeLog,1.101,1.102

[The Wanderer]

Diego Biurrun wrote:

> The Wanderer writes:
> 
>> Diego Biurrun CVS wrote:
>> 
>>> -    * native SPARC VIS optimizations
>>> +    * native Sparc VIS optimizations
>> 
>> As I understand it, "SPARC" is in fact an acronym; VERA lists it as
>> "Scalable Processor ARChitecture". Unless this line actually
>> refers to something else I'm missing, the all-caps form would be
>> the appropriate one.
> 
> Heh, I went to sun.com and saw it written as "Sparc" on their front
> page, go figure.  But SPARC is right.

It hasn't been corrected yet, though - which I wouldn't mention, except
that the others I noted have, so it's possible that this was an
oversight.

> OK, just found out what V.E.R.A (Virtual Entity of Relevant Acronyms)
> is, very useful, thanks.  Do you know an online version that has a
> good search function?

Unfortunately, no. I found it in the first place while going hog-wild
installing dict-compatible dictionaries, so I just use dict to access
it.

>>> -  - VCD-related stuff moved from stream.c to vcd_read.c
>>> +  - VCD related stuff moved from stream.c to vcd_read.c
>> 
>> This is incorrect - the hyphen belongs there.
> 
> I agree on second thought.  What is the explicit rule for when to use
> hyphens to compose words in English?

I don't know formally, but in this instance it's because you're using
"VCD-related" as an adjective, and as such its component words need to
be bound together; a hyphen is simply the usual way of doing that. (This
may not be an official rule, but it applies universally for clear
comprehension as far as I'm concerned.)

>> As noted, there were about four more arguable and/or less important
>> things I noticed but didn't mention; I don't want to get too
>> nitpicky and annoying, though it may be too late to worry about
>> that.
> 
> It's far too late for that ;)
> 
> But don't you worry, if I weren't nitpicky as well I wouldn't be
> discussing these things with you, would I? ;)

Well, no. And I knew I was being nitpicky and annoying, I just didn't
want to get *too* nitpicky and annoying. There are limits, after all.

> So feel free to bring on the rest, I'm interested.

Will do if I can find them again, when I have a chance - which given the
hour may not be soon. (Too many things to do, not enough initiative to
get up and do them... and I work tomorrow.)

> While we are at the subject: I'm unsure about the correct of spelling
> of "vobsub" vs "VobSub" vs "VOBsub" vs "VOBSub" vs "VOBSUB" and all
> five variants are used throughout MPlayer.  There is a VirtualDub 
> plugin/filter called VobSub, so maybe that is where part of the 
> confusion originates.  I'm inclined to use "VOBsub".  Since we use
> VOB for Video OBject this seems like the most logical spelling for
> me.

I've had problems trying to figure that one out myself; your suggestion
makes sense, but I'd be content with any (sane) official pronouncement
so I could be sure in future of getting it right.

>> (Hey, even if I don't understand most of the actual code, maybe I
>> can at least contribute by going over things like this....)
> 
> Definitely.  There are lots of things that need to be done in this
> area.  Off the top of my head:
> 
> * Completely review the docs - they are mostly still written in
>   Hunglish and much of it is clumsy and/or hard to understand. Such a
>   review would of course be a good opportunity to extend them.
> * Same thing but for the tech docs.

The problem with both of these is that, for some of the same reasons as
I don't understand the code, I don't really know how most of the program
works well enough to improve on what descriptions I know about. I've
been picking things up here and there by mostly-lurking on the mailing
lists, but my overall knowledge is still quite limited.

I suppose I could go reading through the HTML documentation and so
forth, and see if I spot anything I could explain better... in my
copious spare time. :)

> * Much of the output MPlayer prints to the console is poor with
>   regard to spelling, wording and clarity.  Also we have many printfs
>   that ought to be converted to mp_msg calls.  These tasks naturally go
>   together.

I actually took on the latter of these (printf --> mp_msg) once, but ran
into the problem of choosing what MSGT and MSGL to use. It was agreed to
define MSGL_FIXME, so that people who actually know that part of the
code well enough to make the decision could more easily find and change
the problem spots, but the question of what MSGT(s) to use was never
resolved and I ended up stopping work on the endeavour. If these two
problems can be resolved, I could start over again, but as things stand
my lack of knowledge of the code gets in the way.

One thing I could do regardless is keep a watch on this mailing list and
point out any commits with printfs or similar (sort of like I've been
doing with mistakes in these spellcheck commits); by itself this won't
fix the existing problems in that respect, but it would help prevent
them from getting any worse.

As to poorly-done text output - I'll keep my eyes open, and if I see
anything I can with confidence improve upon, I'll point it out.
Code-diving (or even just -searching) in search of these things will
have to wait at least until my work schedule slows down, which will
happen no later than November (but probably much earlier).

> * to be continued...
> 
> So if you are willing to help this would be most welcome.  I badly
> need a hand atm.  Between MPlayer development, documenation, website,
> release and legal stuff in its current intensity, work, university
> and maybe something else the days are getting really really short..

Well, I'm not sure (as noted) how much help I could be, and my own time
is more limited than I'm used to (though much less than it could be),
but if there's anything specific I *can* do feel free to ask; there's
little I like more than helping out.

> BTW, this would also legitimize your presence on mplayer-legal ;-)

<grin>

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.