[MPlayer-dev-eng] documentation HOWTO

[Arpi]

Hi,

> Diego Biurrun wrote:
> > the most common spelling errors
> Arpi's "teh" instead of "the" :) Rarely "eth" :)

never eth, it would mean swapped order of 'e' and 't'.
i'm typing using ~7 fingers, so you can easily calculate that it
means 2 hands. the order of keypresses inside a hand is ok, but
the nerve connection between brain and hands is unreliable
(maybe i should switch from slip to ppp?:)) so sometimes the commands
to left hand arrives earlier than should so e beats h.
I think it's a bidirectional connection problem. let's see how are you typing:
1. send comamnd to right hand to press 't'
2. wait for response 't appeared on screen'
3. send command to right hand to press 'h'
4. wait for response 'h appeared on screen'
5. send command to left hand to press 'e'
6. wait for response 'e appeared on screen'
7. verify if the order of chars are ok.

now, 7 steps is at least 7 clocks, but actually more. it's sloooooooow!
(and it's much more for longer words!)
so i've optimized it a bit. i'm interleaving steps 1..3 with 5, and
left out not-so-important 4. and 6..7.
the result is amazing, i type faster than my mother who uses 10 fingers!
(and i wasn't even compiled with gcc 3.2!)
but there is a bug, a race condition between steps 3 and 5 :(
when i received completion event from step 2, i send both 3. and 5, with
a very little delay. in thery, 1ns delay should be enough to complete 3
before 5, but the connection is slower and unreliable so 3. sometimes fails
and 5. completes earlier. but 5. may fai ltoo, so i need quite big delay
to be sure, but it either delays next word or slows down typing a lot.
i'm trying to change cpu timings to get rid of it, but it results other
bugs, usually space placed at wrong place (one char too early or late).
maybe i should try typing ECC and let the editor verify and correct my
data transfer bugs. but it's also big overload, more data to transfer and a
lot of cpu time calculating ECC for each line.

after some investigation i've found that the failure in most cases happens
while pressing the key, so keypress elimination could eliminate bugs too.
it seems i'm not only with this opinion, NASA scientists already found this
years ago, and developed a much more powerfull system:

http://amesnews.arc.nasa.gov/releases/2001/01_08AR.html
http://amesnews.arc.nasa.gov/releases/2001/01images/bioelectric/0001832.JPG

it was so successful, that the test pilot can land an airplane using a
single hand. just imagine if he would develop mplayer using the other hand!

> >   - 79 (80?) chars wide text
> 80 is also fine

no, 80 causes automatic linewrap at EOL, so you get empty line due to \n.
and if you left out \n then it won't work on non-80 wide terminals!

> Also avoid double spaces "  "

yes, it's a big waste of disk space!
we should remove double spaces from the sourcecode too.
who the fsck needs indenting? :)

> >   text docs
> >   - 79 chars wide text
> 80
> We're not on Commodore 64 where newline characters require one byte :)
we aren't on c64, but pc terminals just behave the same way. since it's not
c64 related by ascii related.

so it's 79, not 80!


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
    "However, many people beg for its inclusion in Debian. Why?" - Gabucino
  "Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino