Hi All! Files: find_sub.c, sub_cc.c, subreader.c liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c libdha: pci.c, sysdep/libdha_win32.c, sysdep/pci_win32.c libmenu: menu.c, menu_cmdlist.c, menu_console.c, menu_filesel.c, menu_param.c, menu_pt.c, menu_txt.c, vf_menu.c libmpcodecs: ad_libdv.c, mp_image.h, pullup.c, vd_dmo.c, vd_dshow.c, vd_ffmpeg.c, vd_realvid.c, vd_vfw.c, ve_lavc.c, ve_raw.c, ve_vfw.c, vf.c, vf_crop.c, vf_cropdetect.c, vf_expand.c, vf_fame.c, vf_format.c, vf_framestep.c, vf_noformat.c, vf_palette.c, vf_phase.c, vf_test.c, vf_tile.c, vf_yuy2.c, vf_yuy9.c libmpdemux: cache2.c, cddb.c, demux_asf.c, demux_audio.c, demux_demuxers.c, demux_film.c, demux_gif.c, demux_mov.c, demux_nuv.c, demux_real.c, demux_viv.c, demux_xmms.c, stream.c, tvi_v4l2.c, video.c libvo:aspect.c, mga_common.c, vesa_lvo.c, video_out.c, vo_3dfx.c, vo_dxr3.c, vo_mga.c, vo_null.c, vo_png.c, vo_sdl.c, vosub_vidix.c, vo_svga.c, vo_syncfb.c, vo_tdfxfb.c, vo_tdfx_vid.c, vo_tga.c, vo_vesa.c, vo_x11.c, vo_xv.c Best regards! Attila
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
Hi All!
Files: find_sub.c, sub_cc.c, subreader.c liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c libdha: pci.c, sysdep/libdha_win32.c, sysdep/pci_win32.c libmenu: menu.c, menu_cmdlist.c, menu_console.c, menu_filesel.c, menu_param.c, menu_pt.c, menu_txt.c, vf_menu.c libmpcodecs: ad_libdv.c, mp_image.h, pullup.c, vd_dmo.c, vd_dshow.c, vd_ffmpeg.c, ^^^^^^^^
Changes to pullup.c rejected. Either add a callback function for messages to the pullup context or skip this one. But using mplayer functions in pullup.c is not acceptable. BTW printf is only used when verbose is set in the context anyway. Rich
2006. március 19. 20.03 dátummal Rich Felker ezt írta:
Changes to pullup.c rejected. Either add a callback function for messages to the pullup context or skip this one. But using mplayer functions in pullup.c is not acceptable. BTW printf is only used when verbose is set in the context anyway. I sorry! My mistake pullup.c exist in file list. The patch don't modify pullup.c.
Best regards! Attila
On Sun, Mar 19, 2006 at 08:19:53PM +0100, Ötvös Attila wrote:
2006. március 19. 20.03 dátummal Rich Felker ezt írta:
Changes to pullup.c rejected. Either add a callback function for messages to the pullup context or skip this one. But using mplayer functions in pullup.c is not acceptable. BTW printf is only used when verbose is set in the context anyway. I sorry! My mistake pullup.c exist in file list. The patch don't modify pullup.c.
Best regards! Attila
Hi Attila, I just skimmed the patch, looks ok, Ill try to take a deeper look at it tomorrow morning. Im trying to modify our message rutines to use catgets so please give me some more time to review. Thanks for your work Best regards Reynaldo
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it. You have a few hunks like the following in the patch: - if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n"); Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should. Diego
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X is just error prone, duplicated work and useles code polution IMHO. Best regards Reynaldo
On Sun, Mar 19, 2006 at 06:54:27PM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X is just error prone, duplicated work and useles code polution IMHO.
No, the few cases where this is done it's critical -- at least for the few I know. The performance penalty of calling mp_msg over and over in these instances was deemed unacceptable so it was put under conditional. Rich
On Sun, Mar 19, 2006 at 11:35:36PM -0500, Rich Felker wrote:
On Sun, Mar 19, 2006 at 06:54:27PM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, ?tv?s Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X is just error prone, duplicated work and useles code polution IMHO.
No, the few cases where this is done it's critical -- at least for the few I know. The performance penalty of calling mp_msg over and over in these instances was deemed unacceptable so it was put under conditional.
These should be changed to mp_msg_test, and, there's no gain if the if is put before a single mp_msg, it is only worth it if the if is preventing a whole loop of it. (mp_msg returns immediately if message is not going to be printed, no formatting or anything) - ods15
On Mon, Mar 20, 2006 at 06:37:46AM +0200, Oded Shimon wrote:
On Sun, Mar 19, 2006 at 11:35:36PM -0500, Rich Felker wrote:
On Sun, Mar 19, 2006 at 06:54:27PM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, ?tv?s Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X is just error prone, duplicated work and useles code polution IMHO.
No, the few cases where this is done it's critical -- at least for the few I know. The performance penalty of calling mp_msg over and over in these instances was deemed unacceptable so it was put under conditional.
These should be changed to mp_msg_test, and, there's no gain if the if is put before a single mp_msg, it is only worth it if the if is preventing a whole loop of it. (mp_msg returns immediately if message is not going to be printed, no formatting or anything)
However this is totally not the case if something evil like gettext is used, and there's even some (much smaller, O(1)) price to pay even with catgets. Even without, a function call and conditional costs more than a conditional alone. Rich
On Sun, Mar 19, 2006 at 11:35:36PM -0500, Rich Felker wrote:
On Sun, Mar 19, 2006 at 06:54:27PM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X
a missing line here: "just for preventing an mp_msg when a certain condition of verbosity level is not meet"
is just error prone, duplicated work and useles code polution IMHO.
No, the few cases where this is done it's critical -- at least for the few I know. The performance penalty of calling mp_msg over and over in these instances was deemed unacceptable so it was put under conditional.
from mp_msg.c: void mp_msg(int mod, int lev, const char *format, ... ){ va_list va; char tmp[MSGSIZE_MAX]; if (!mp_msg_test(mod, lev)) return; // do not display I know this is somewhat slower than if() but, its really that slow? so to be forced to check for it outside the mp_msg call?
Rich
Best regards Reynaldo
On Sun, 19 Mar 2006 23:35:36 -0500 Rich Felker <dalias@aerifal.cx> wrote:
On Sun, Mar 19, 2006 at 06:54:27PM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X is just error prone, duplicated work and useles code polution IMHO.
No, the few cases where this is done it's critical -- at least for the few I know. The performance penalty of calling mp_msg over and over in these instances was deemed unacceptable so it was put under conditional.
In case you don't know about it, in such cases you can also use the mp_dbg() macro. It expand to mp_msg only in debug builds. Albeu
On Mon, Mar 20, 2006 at 02:41:52PM +0100, Alban Bedel wrote:
On Sun, 19 Mar 2006 23:35:36 -0500 Rich Felker <dalias@aerifal.cx> wrote:
On Sun, Mar 19, 2006 at 06:54:27PM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 11:34:00PM +0100, Diego Biurrun wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
liba52: parse.c, ao_oss.c, ao_sun.c, audio_out.c
This is an imported library, don't patch it.
You have a few hunks like the following in the patch:
- if(verbose > 4) - printf("vd_ffmpeg::mc_get_buffer\n"); +// if(verbose > 4) + mp_msg(MSGT_DECVIDEO, MSGL_DBG4, "vd_ffmpeg::mc_get_buffer\n");
Somebody correct me if I am wrong, but I believe this is incorrect, since now the call to mp_msg will not be skipped as it should.
Diego
I prefer the later, having if(verbose >|<|= X) clauses _and_ MSGL_X is just error prone, duplicated work and useles code polution IMHO.
No, the few cases where this is done it's critical -- at least for the few I know. The performance penalty of calling mp_msg over and over in these instances was deemed unacceptable so it was put under conditional.
In case you don't know about it, in such cases you can also use the mp_dbg() macro. It expand to mp_msg only in debug builds.
Debug build is very different from verbose==4 and is not the intended semantics. Rich
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
Hi All!
Files:
[cut]
Best regards! Attila
* Not really sure but: - MSGTR_MPLIBAO2_UnkkownSupportedOSSFromat "Unknown/not supported OSS format: %x\n" + MSGTR_MPLIBAO2_UnkkownSupportedOSSFromat "Unknown/Not supported OSS format: %x\n" * Just to stay consistent with: MSGTR_MemAllocFailed "Memory allocation failed\n": - MSGTR_LIBMENU_MallocError "malloc error: %s" + MSGTR_LIBMENU_MAllocError "Memory allocation error: %s" * Check phrasing on this ones: MSGTR_LIBMENU_MenuTxtNeedATxtFileName "Menu txt need a txt file name (param file)\n" (sounds weird) MSGTR_LIBMENU_MenuTxtCantOpen "Menu txt can't open: %s\n" (sounds weird) MSGTR_LIBMENU_WarningTooLongLineSplitting "Warning too long line, splitting it\n" (Warning, string too long, splitting it ?) MSGTR_LIBVO_Dxr3UseUnknownNormSuppliedCurrentNorm "Unknown norm supplied. Use current norm" (Using ?) * The '[(all caps?)string]' form is used everywhere when messages are preceeded by code module identifiers (?) please check all ocurrences of variants ([string:] / string: / .. ) and adjust to fit common use. as in: MSGTR_LIBVO_MgaUsingBuffers "[mga] Using %d buffers.\n" MSGTR_LIBVO_VomgaCouldntOpen "vo_mga: Couldn't open %s\n" MSGTR_LIBVO_Display3dfxInitialized "(display) 3dfx initialized %p\n" there are several if you cant make it so your patch stays consistent in form and phrasing with the master help_mp-en please do your best to at last check it is consistent within itself. * Check for correct use of caps in the first letter of most messages. * Check for period (.) at the end of 'complete sentence' messages. Im not a native eng speaker neither, so i know the feeling ;) if you need some help just check and repost. Best regards and thanks again for your work. Reynaldo
Reynaldo H. Verdejo Pinochet wrote:
On Sun, Mar 19, 2006 at 07:24:37PM +0100, Ötvös Attila wrote:
Hi All!
Files:
[cut]
Best regards! Attila
* Not really sure but:
- MSGTR_MPLIBAO2_UnkkownSupportedOSSFromat "Unknown/not supported OSS format: %x\n" + MSGTR_MPLIBAO2_UnkkownSupportedOSSFromat "Unknown/Not supported OSS format: %x\n"
The original form isn't ideal, but the new form isn't an improvement; the "Not" should not be capitalized. The better fix would be to say "unsupported" instead, for parallelism with "Unknown". (Also, the MSGTR name uses "Unkkown"; looks like a typo, but depending on how many places this is used the fix might be intrusive enough to not be worthwhile.)
* Just to stay consistent with: MSGTR_MemAllocFailed "Memory allocation failed\n":
- MSGTR_LIBMENU_MallocError "malloc error: %s" + MSGTR_LIBMENU_MAllocError "Memory allocation error: %s"
This is not necessarily correct, depending on whether or not the "memory allocation" referred to in MemAllocFailed is done with malloc. From the MSGTR names, it looks as if the former could be referring to any memory allocation, and the latter only to malloc. This is, however, minor. (If such a change *is* made, incidentally, I would recommend extending the MSGTR to MSGTR_LIBMENU_MemAllocError - rather than just capitalizing the A - for consistency with the example you gave.)
* Check phrasing on this ones:
MSGTR_LIBMENU_MenuTxtNeedATxtFileName "Menu txt need a txt file name (param file)\n" (sounds weird)
Very. I have no idea what it even *means*, so I can't really try to rephrase it. Is it talking about a file called "menu.txt", or does it want the word "text" there, or is there something I haven't thought of? In any case, instead of "txt file", it should be either "text file" or ".txt file".
MSGTR_LIBMENU_MenuTxtCantOpen "Menu txt can't open: %s\n" (sounds weird)
Same problem here, I don't know what it means.
MSGTR_LIBMENU_WarningTooLongLineSplitting "Warning too long line, splitting it\n" (Warning, string too long, splitting it ?)
Both forms have comma issues, and yes, "too long" should come after the noun rather than before. The comma issues could be avoided perhaps most simply by replacing the latter with an emdash, of whatever form is preferred.
MSGTR_LIBVO_Dxr3UseUnknownNormSuppliedCurrentNorm "Unknown norm supplied. Use current norm" (Using ?)
Again, I don't know what this means, because I don't know what a "norm" is in this context. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
2006. március 20. 22.02 dátummal The Wanderer ezt írta:
(If such a change *is* made, incidentally, I would recommend extending the MSGTR to MSGTR_LIBMENU_MemAllocError - rather than just capitalizing the A - for consistency with the example you gave.)
* Check phrasing on this ones:
MSGTR_LIBMENU_MenuTxtNeedATxtFileName "Menu txt need a txt file name (param file)\n" (sounds weird)
Don't settings text file name in menu.conf. Example: <txt name="man" file="manpage.txt">
Very. I have no idea what it even *means*, so I can't really try to rephrase it. Is it talking about a file called "menu.txt", or does it want the word "text" there, or is there something I haven't thought of?
In any case, instead of "txt file", it should be either "text file" or ".txt file".
MSGTR_LIBMENU_MenuTxtCantOpen "Menu txt can't open: %s\n" (sounds weird)
Same problem here, I don't know what it means.
MSGTR_LIBMENU_WarningTooLongLineSplitting "Warning too long line, splitting it\n" (Warning, string too long, splitting it ?)
Both forms have comma issues, and yes, "too long" should come after the noun rather than before. The comma issues could be avoided perhaps most simply by replacing the latter with an emdash, of whatever form is preferred.
I can't do. I am sorry to say that my English knowledge isn't good. I cosmetics printf patch: - standartized modul name eg: [LIBA52] - upper case first char in sentence - closed sentence with point "." Best regards! Attila
On Mon, Mar 20, 2006 at 10:41:07PM +0100, Ötvös Attila wrote:
I cosmetics printf patch: - standartized modul name eg: [LIBA52] - upper case first char in sentence - closed sentence with point "."
You still have removed the if(verbose) conditionals in places. This is not correct. I have just made a patch that replaces them by mp_msg_test calls. I'll just commit it before your patch goes in. Diego
2006. március 20. 23.05 dátummal Diego Biurrun ezt írta:
On Mon, Mar 20, 2006 at 10:41:07PM +0100, Ötvös Attila wrote:
I cosmetics printf patch: - standartized modul name eg: [LIBA52] - upper case first char in sentence - closed sentence with point "."
You still have removed the if(verbose) conditionals in places. This is not correct. I have just made a patch that replaces them by mp_msg_test calls. I'll just commit it before your patch goes in.
I remove if(verbose) but still some places. Example: --- libmpdemux/demux_asf.c 2006-02-17 02:57:40.000000000 +0100 +++ libmpdemux/demux_asf.c 2006-03-20 23:13:18.000000000 +0100 @@ -180,8 +180,8 @@ if(verbose>1){ int i; - for(i=0;i<16;i++) printf(" %02X",asf_packet[i]); - printf("\n"); + for(i=0;i<16;i++) mp_msg(MSGT_DEMUX,MSGL_V, "%02X",asf_packet[i]); + mp_msg(MSGT_DEMUX,MSGL_V,"\n"); } // skip ECC data if present by testing bit 7 of flags Best regards! Attila
On Tue, Mar 21, 2006 at 12:27:42AM +0100, Ötvös Attila wrote:
2006. március 20. 23.05 dátummal Diego Biurrun ezt írta:
On Mon, Mar 20, 2006 at 10:41:07PM +0100, Ötvös Attila wrote:
I cosmetics printf patch: - standartized modul name eg: [LIBA52] - upper case first char in sentence - closed sentence with point "."
You still have removed the if(verbose) conditionals in places. This is not correct. I have just made a patch that replaces them by mp_msg_test calls. I'll just commit it before your patch goes in.
I remove if(verbose) but still some places.
They are still in some places. Don't worry about it, though, I'll have them replaced in a few days anyway. Diego
On Tue, Mar 21, 2006 at 08:48:24AM +0100, Diego Biurrun wrote:
On Tue, Mar 21, 2006 at 12:27:42AM +0100, Ötvös Attila wrote:
2006. március 20. 23.05 dátummal Diego Biurrun ezt írta:
On Mon, Mar 20, 2006 at 10:41:07PM +0100, Ötvös Attila wrote:
I cosmetics printf patch: - standartized modul name eg: [LIBA52] - upper case first char in sentence - closed sentence with point "."
You still have removed the if(verbose) conditionals in places. This is not correct. I have just made a patch that replaces them by mp_msg_test calls. I'll just commit it before your patch goes in.
I remove if(verbose) but still some places.
They are still in some places. Don't worry about it, though, I'll have them replaced in a few days anyway.
Diego
Ok to commit after already asked corrections then? Reynaldo
On Tue, Mar 21, 2006 at 11:29:24AM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Tue, Mar 21, 2006 at 08:48:24AM +0100, Diego Biurrun wrote:
On Tue, Mar 21, 2006 at 12:27:42AM +0100, Ötvös Attila wrote:
2006. március 20. 23.05 dátummal Diego Biurrun ezt írta:
On Mon, Mar 20, 2006 at 10:41:07PM +0100, Ötvös Attila wrote:
I cosmetics printf patch: - standartized modul name eg: [LIBA52] - upper case first char in sentence - closed sentence with point "."
You still have removed the if(verbose) conditionals in places. This is not correct. I have just made a patch that replaces them by mp_msg_test calls. I'll just commit it before your patch goes in.
I remove if(verbose) but still some places.
They are still in some places. Don't worry about it, though, I'll have them replaced in a few days anyway.
Ok to commit after already asked corrections then?
No, the patch in its current form is wrong. Please let this matter rest until I have committed my mp_msg_test changes. I have finished implementing this yesterday, but I need to double-check my changes before committing, I'm sure there are still a few hidden 10l typos inside. Diego
On Sun, March 19, 2006 10:24, Ötvös Attila wrote:
Hi All!
I've attached an edited diff with a bunch of spelling and grammer errors corrected. I'm sleepy and I'm sure I missed several (I even misspelled "grammar" in the last sentence), but this should be somewhat of an improvement. Note that I have ignored the other comments in this thread in order to avoid duplicating your work -- you may want to diff my diff against your diff to see which changes I made. By the way, that's a huge pile of changes -- it must have taken you a while. Thanks for the effort. -Corey
2006. március 20. 06.42 dátummal Corey Hickey ezt írta:
On Sun, March 19, 2006 10:24, Ötvös Attila wrote:
Hi All!
I've attached an edited diff with a bunch of spelling and grammer errors corrected. I'm sleepy and I'm sure I missed several (I even misspelled "grammar" in the last sentence), but this should be somewhat of an improvement.
Note that I have ignored the other comments in this thread in order to avoid duplicating your work -- you may want to diff my diff against your diff to see which changes I made.
By the way, that's a huge pile of changes -- it must have taken you a while. Thanks for the effort.
-Corey Thank you! I applied.
Best regards! Attila
On Mon, Mar 20, 2006 at 10:31:53PM +0100, Ötvös Attila wrote:
2006. március 20. 06.42 dátummal Corey Hickey ezt írta:
On Sun, March 19, 2006 10:24, Ötvös Attila wrote:
Hi All!
I've attached an edited diff with a bunch of spelling and grammer errors corrected. I'm sleepy and I'm sure I missed several (I even misspelled "grammar" in the last sentence), but this should be somewhat of an improvement.
Note that I have ignored the other comments in this thread in order to avoid duplicating your work -- you may want to diff my diff against your diff to see which changes I made.
By the way, that's a huge pile of changes -- it must have taken you a while. Thanks for the effort.
-Corey Thank you! I applied.
Best regards! Attila
Commited, with TONS of changes, keep the good work Otvos, Im sure next one will be better ;) Best regards and thanks again Reynaldo H. Verdejo Pinochet
On Mon, Apr 24, 2006 at 12:54:50AM -0400, Reynaldo H. Verdejo Pinochet wrote:
On Mon, Mar 20, 2006 at 10:31:53PM +0100, Ötvös Attila wrote:
2006. március 20. 06.42 dátummal Corey Hickey ezt írta:
On Sun, March 19, 2006 10:24, Ötvös Attila wrote:
Hi All!
I've attached an edited diff with a bunch of spelling and grammer errors corrected. I'm sleepy and I'm sure I missed several (I even misspelled "grammar" in the last sentence), but this should be somewhat of an improvement.
Note that I have ignored the other comments in this thread in order to avoid duplicating your work -- you may want to diff my diff against your diff to see which changes I made.
By the way, that's a huge pile of changes -- it must have taken you a while. Thanks for the effort.
-Corey Thank you! I applied.
Best regards! Attila
Commited, with TONS of changes, keep the good work Otvos, Im sure next one will be better ;)
Best regards and thanks again
Reynaldo H. Verdejo Pinochet
Attila, I am adding you to AUTHORS for this changes, your entry is: Ötvös, Attila <oattila@chello.hu> * A huge pile of printf to mp_msg patches Let me know if its ok with you. Regards Reynaldo
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
participants (8)
-
Alban Bedel -
Corey Hickey -
Diego Biurrun -
Oded Shimon -
Reynaldo H. Verdejo Pinochet -
Rich Felker -
The Wanderer -
Ötvös Attila