Am Freitag, 27. Juli 2007 21:39:51 schrieben Sie: > Uwe Bugla wrote: > > Am Freitag, 27. Juli 2007 04:27:59 schrieben Sie: > >> P. van Gaans wrote: > >>> Uwe Bugla wrote: > >>>> Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie: > >>>>> Uwe Bugla wrote: > >>>>>> Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: > >>>>>>> I don't call myself a programmer (I've never seen any C guide), but > >>>>>>> somehow I figured out how to add an extra switch to tzap to make it > >>>>>>> print the status in (human-readable) decimal instead of hex. It is > >>>>>>> attached. It would be really nice if this would make it into the > >>>>>>> dvb-apps on linuxtv.. > >>>>>>> > >>>>>>> Talking about that, could anybody tell me the minimal and maximal > >>>>>>> and/or > >>>>>>> possible values for status, signal, snr, ber and uncorrected? If I > >>>>>>> would > >>>>>>> know them I could try to make the numbers more human-readable (eg > >>>>>>> signal > >>>>>>> ranging from 0 to 99 or so). > >>>>>> > >>>>>> Could you please redo that: > >>>>>> - in patch format (=only the additions) > >>>>>> - equally for tzap, czap, szap and femon? > >>>>>> > >>>>>> Thus everybody could take advantage from that idea. > >>>>>> Would be a pleasure for us all if you did! > >>>>>> > >>>>>> My idea for further enlargement (a quite old idea of mine): > >>>>>> route the human readable numbers into a speech recognition engine > >>>>>> (festival) to make them auditable and thus real usable for DVB-S > >>>>>> dish tuning f. ex. > >>>>>> > >>>>>> Note: If the DVB-S dish is far away from the machine (card), > >>>>>> auditable signals are necessary. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> linux-dvb mailing list > >>>>>> linux-dvb@xxxxxxxxxxx > >>>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > >>>>> > >>>>> In patch format.. Oh please.. I have no idea how to produce that! I > >>>>> installed xxdiff, it perfectly shows what I've changed but I don't > >>>>> see an option to save it to a patch file! > >>>>> > >>>>> You're lucky I've got a satellite dish so I should also be able to > >>>>> patch szap and femon. I'll also produce a patched version of czap but > >>>>> my cable card is not installed ATM and I don't feel like doing so > >>>>> (cable provider is crap) but I'll probably get someone else on this > >>>>> list to test it. > >>>>> > >>>>> Please do not try to add the switch yourself without asking me if I'm > >>>>> still working on it. Nobody needs double work. > >>>>> > >>>>> If somebody can tell me how to produce the so much wanted .diff files > >>>>> I'll start working on it. > >>>> > >>>> A. Take the latest kernel patch (i. e. 2.6.21.1) as an example. > >>>> B. format is as follows: > >>>> --- a/(file to be changed) > >>>> +++ b/(file to be changed) > >>>> @@ -(starting line number),(total number of lines starting from the > >>>> beginning line before the change) +(starting line number),(total > >>>> number of lines starting from the beginning line after the change) > >>>> (3 context lines starting with a space) > >>>> (additions start with plus) > >>>> (deletions start with minus) > >>>> (3 context lines starting with a space) > >>>> > >>>> If this explanation still is too abstract, have a look at the example > >>>> again. > >>>> Don't forget to test the patch! > >>>> No fuzz factors, no rejections please. > >>>> For testing purposes keep the original file to be patched in a > >>>> separate directory please. > >>>> Now please give it a try - for sure you gonna make it! > >>> > >>> I've got an idea of how the .diff is constructed, but I simply refuse > >>> to write them by hand. I've bought a computer NOT to do any more boring > >>> repetitive work ;-). > >>> > >>> diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily. > >>> > >>> Tzap was patched already. > >>> Szap patched, compiles, tested and OK. > >>> Czap patched, compiles without errors, untested because I hate my cable > >>> provider and the box I would have to install the cable card in is > >>> really noisy and unstable. Whoever wants to test: please report > >>> results, czap looks a little different from szap and tzap but I'm > >>> pretty certain it'll work straightaway. I assume this is OK, you > >>> couldn't expect all linuxtv developers to own cards for all DVB-systems > >>> anyway.. > >>> Femon patched in a different way: Femon already has a "human readable" > >>> switch, I just made BER and uncorrected show up as decimal instead of > >>> hex in human readable mode. Adding another switch sounds pointless to > >>> me. > >>> > >>> The numbers/output seem to differ between devices and between szap and > >>> tzap greatly so for now I'm not going to try to make them more > >>> human-readable because of the possibility of breaking something. > >>> > >>> Everything attached. > >>> > >>> > >>> > >>> > >>> ----------------------------------------------------------------------- > >>>- > >>> > >>> _______________________________________________ > >>> linux-dvb mailing list > >>> linux-dvb@xxxxxxxxxxx > >>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > >> > >> There was some confusion cause of Uwe, but will my switch ever make it > >> to the dvb-apps on linuxtv? Or is there something wrong with it? > > > > I did not want to cause any confusion at all, but I just transformed your > > work into a patch format that is expected everywhere in the linux world > > if you want your stuff to be merged. > > > > As it was refused as a whole (patched dvb-apps) I decided to resend it to > > Christoph Pfister CCing you. > > > > Everybody's waiting for Christoph Pfister now. > > > > Cheers > > > > Uwe > > Yes, I saw that mail a little later after my reply was already sent. > > It seems the "patch format" is just all my diff files following up each > other in one file? If that's the expected format, good to know. Yes and No! A. As far as Andrew Morton's "perfect patch rules" are concerned I broke the "golden rule" (i. e. one patch per Email!) B. As far as Andrew Morton's "perfect patch rules" are concerned I broke another "golden rule": Missing the SOB: (i. e. "Signed-off-by: blabla@xxxxxxxxxx) f. ex. C. As far as the linuxtv.org "illustrious" "maintainers" are concerned I obviously forgot to mention that every kind of activity of those guys is highly "mood-oriented": That means several things in practice: 1. You can NEVER be sure that your contributions are merged if you do not belong to the "illustrious", i. e. gatekeepers. 2. The list of "maintainers" shown at http://www.linuxtv.org/hg/ is just one big mess: You cannot find out who is responsible for what and who is active or not. Reliability seems to be a foreign word for the politics Mister Mauro Carvalho Chehab (called "The horse" - the english translation for the spanish expression "carvalho", but claiming: I AM THE BOSS, although it's proven by science that a horse cannot even count to 3) has been practising for a long time now. 3. Enhancements from "outsiders" are not welcome at all if you do not belong to the "illustrious", i. e. gatekeepers owing a "repository" at linuxtv.org. 4. But there are some selfish egoists as well disturbing the whole thing by their reactionary lazy-oriented manners (well, if you can call that manners at all! - they DO remind me of kafkaesque (Yes: Franz Kafka I DO mean) gatekeepers): Their names are: Manu Abraham (abraham.manu@xxxxxxxxx) and Oliver Endriss at first, but other "politicians" or self-established narrow-brained "gurus" like Johannes Stezenbach (js@xxxxxxxxxxx) not being forgotten. 5. The consequence of point 4. was that Markus Rechberger (mrechberger@xxxxxxxxx) left the linuxtv project. 6. But the "structural" trouble is unfortunately not a structural linuxtv.org-specific: The structural problems of linuxtv-"maintainership" are just another metastasis of a growing cancer which is called "transformation of human brains towards a pro-capitalist manner idealizing bum trip egoism as the only rule of human behaviour". For those brains altruism is a foreign word, egoism and darwinism rules everything. Those people ain't human beings, are they? IMHO they are nothing but mismatches of human mankind production! Today I read at http://www.linux-magazin.de/news/kernel_entwickler_kolivas_wirft_das_handtuch that the Australian kernel developer Con Kolivas quit the kernel development. His only "crime" was that he wanted to make the i386 systems a bit faster by some swap-prefetch-patches. But those swap-prefetch-patches (meaning something positive) were never accepted due to some reactionary lazy dumb other goddamn egoist linux kernel developers! The truly amazing utmost hypocritic asshole thing about that is that Linus Torvalds once wrote me that it is "impossible to win voluntary developers for linux". Mister Linus Torvalds would DO very well reflecting the origins he once started up with and where he came from instead of telling me and others those utmost hypocritic lies! Linus Torvalds's and Andrew Morton's basic "moral" seems to be: The "Toyota" principle going: "Nothing is impossible - Toyota" Or expressed in other words: Paragraph 1: I only see what I want to see! Paragraph 2: What I do not want to see does not exist! Paragraph 3: Every kind of criticism is only negative energy, and that's why it goes to /dev/ null and leads to exclusions out of mailing lists to ensure myself a more less problematic life! Positive Perspectives? Mister Hugo Chavez is doing well in Latin America! Happy reflection about your bum trip egoisms wasting up everything!!!! P.S.: Egoistic and lazy developers bypassing the GPL in practice and chasing away people trying to improve the kernel or even sub parts of it or applications should be consequently banned from all world-wide linux development! There can only be a balance of egoism and altruism, but there can never be a rulership of TOTAL egoism and laziness! If there is a rulership of total egoism the contaminated people in question gotta be banned and wiped out without return ticket! _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
