aMule Forum
English => Feature requests => Topic started by: gagar on May 31, 2011, 09:25:15 AM
-
Hey guys,
Now that I saw that the next version of aMule was coming, I wanted to suggest some additional file formats that could be, IMHO, usefully recognized. I'm thinking to OOo files and Ogg Theora videos along with a couple of other formats. Please see the attached patch for OtherFunctions.cpp for details (it should correspond to the latest version of the file which I fetched from the git repo at repo.or.cz/w/amule.git but please double check it).
I performed a global search for all of the file types and there were results, except for some OOo template files which I added anyway because their equivalent versions for Microsoft Office were already there.
Of course, if you think something's stupid feel free to say it. People often say that I do weird things, so... :)
-
Are there really still zoo files around ? That format was dying out in the 80s iirc.
Anyway I like your patch. Do me a favor and post just the modified file here (instead of the diff) and I'll commit it.
-
Thanks for your answer. I attached the patched OtherFunctions.cpp in uncompressed form as I think I read on another thread that you preferred such versions.
And yeah, zoo is pretty rare nowadays, but you still stumble upon interesting stuff in this format from time to time, especially for those who remember the golden age of Amiga.
-
Stu prefers files like that. Everyone else prefers diff files.
-
Committed, thank you!
I don't care if compressed or not, but I don't like booting Linux and wrestling with "patch" if I can avoid it easily. :)
-
I don't care if compressed or not, but I don't like booting Linux and wrestling with "patch" if I can avoid it easily. :)
There are zillions of patch utils for windows.
-
None of which works as supposed to.
-
None of which works as supposed to.
Just googled "patch windows" and got: http://gnuwin32.sourceforge.net/packages/patch.htm
Just tried it and seems to work.
-
On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be used as line endings. A file with LF may give the error: "Assertion failed, hunk, file patch.c, line 343," unless the option '--binary' is given.
Problems start with the combinations of lf / cr-lf that can occur both in the sources to be patched and in the patches themselves.
Proggy needs some manifest to even run without admin rights.
I actually have it installed, and aborted it again because it just didn't work right.
-
Even tortoisesvn/git come with a program to apply patches.
-
Which fails unless the patch was created with SVN. :(
Guys, it's simple. I can apply diff patches. I just have to fire up my Ubuntu-vm, drop the patch in the right place, remember how to call patch correctly, make a dry-run, convert all involved files from crlf to lf format (because the retarded thing fails otherwise), dry-run again until it works, then run for real. It would be slightly easier if our source files were "lf" instead of "native" (or if the Tortoise SVN devs weren't dickheads and made an option to set "native" to lf).
And sometimes I just don't feel like that and tell a contributor to just zip up (or tar-gz or whatever) his modified files and drop them here, because that's much less effort for him than applying the patch is for me.
-
convert all involved files from crlf to lf format (because the retarded thing fails otherwise), dry-run again until it works, then run for real. It would be slightly easier if our source files were "lf" instead of "native" (or if the Tortoise SVN devs weren't dickheads and made an option to set "native" to lf).
Uh, I didn't notice that. Setting svn:eol-style to native only causes trouble, in fact it is a stupid idea. No wonder you can't use patch.
-
So, shold we change the whole SVN tree to LF? Well, except some files that need to have other formats...
-
I sure would like that. (I already changed all build relevant scripts and other files until it worked at last.)
And I don't think there are many Windows users who want to look at the source with notepad.
For the others the change will have no effect. Native storage format in the repo is lf also.
Mac has lf too, right?
-
Technically, Mac has cr.
-
Technically, Mac has cr.
That was before the BSD based system, right? Now unix format should be official.
Regarding the svn repository, our policy is to don't set the svn:eol-style property. That way each file is stored as saved originally, and each user can use the format that suits it more.
-
No, policy is to set the
policy property atm. Which is the right thing to do. You don't want to change each line if a file is checked in in crlf format accidentally. Problem is it should be set to lf instead of native by default.
Or what did you mean with "our" ?
Edit: fixed silly typo
-
Or what did you mean with "our" ?
Sorry I meant "our" == our policy at work. We have hundredths of svn repositories (yes that is not fun).